WEBVTT 00:02.000 --> 00:07.250 Hi, I'm Matt Chung, and I want to talk today about DNS privacy. 00:07.310 --> 00:13.870 Now, usually with DNS, we hear about DNSSEC as in authenticating DNS queries. 00:13.870 --> 00:31.290 Here, I'm interested in a different aspect of DNS security, and that is the privacy of DNS queries to protect users from eavesdroppers finding out what sort of sites they're visiting if they are of sensitive nature. 00:32.050 --> 00:43.350 And I decided to talk about this topic after coming across a paper that I found about a year ago that talked about a novel approach to this problem. 00:43.470 --> 00:56.730 And so I decided to create this talk that goes over some of my experience with this topic over the years, leading up to this paper and some future thoughts about the topic. 00:59.080 --> 01:14.660 To begin with, I'm just going to do a brief introduction to DNS, just a very high-level introduction so that we know what we're talking about, and then we can talk about how we can preserve DNS privacy. 01:16.500 --> 01:28.740 So, at a very high level, DNS, or the domain name system, is a way of translating a host name into an IP address so we can find that on the internet. 01:29.320 --> 01:47.400 And basically, the way that works is when your client is trying to access a site on a host, then it first sends out that host name to its DNS server, which, if it doesn't know it, will try the root name server. 01:47.760 --> 01:59.960 And in this case, if they're looking for www.wikipedia.org, it tries the root name server, and it says, well, I don't know where that is, but try the org name server. 02:00.180 --> 02:06.200 And the org name server may say, I don't know where that is, but try the wikipedia.org name server. 02:06.660 --> 02:12.520 And from there, that name server says, oh, I know, it's this IP address. 02:12.520 --> 02:17.160 So it has this hierarchical structure that it works through recursively. 02:21.030 --> 02:27.910 Now, the first aspect of DNS privacy that I'm going to talk about is what we sort of call local privacy. 02:27.910 --> 02:33.910 It's the first aspect that I considered in terms of my own personal threat model. 02:34.370 --> 02:42.470 And so we'll discuss what the challenge is and some solutions that can easily be undertaken. 02:45.430 --> 02:55.770 So the first situation is you might be browsing the web at a cafe using open Wi-Fi. 02:56.230 --> 03:04.110 And so what I have here is just a screenshot of Wireshark capturing DNS packets. 03:04.490 --> 03:09.950 Now, this isn't particularly for Wi-Fi, but this just gives an example of what that would look like. 03:09.950 --> 03:15.490 Here, we're seeing a DNS query for google.com. 03:15.750 --> 03:26.690 And it would be very simple for somebody with a laptop and Wi-Fi card to sniff traffic like this on open Wi-Fi at a coffee shop. 03:26.730 --> 03:31.830 So as you can see, it's all plain text. 03:31.950 --> 03:39.150 In this case, looking at google.com, it's generally not considered a purely sensitive post. 03:39.150 --> 04:02.730 But if you're looking up information about a health condition or any other issue that you don't want to... or other information that you don't want people to know that you're looking up for the reason if it's not considered socially acceptable, you don't want people to just be able to sniff that information over Wi-Fi. 04:02.730 --> 04:11.550 So the first solution that I considered over the years was to tunnel DNS over SOCKS proxies. 04:11.550 --> 04:24.610 So first, I just wanted to make sure that all traffic was being encrypted, especially 10 plus years ago, not every site was using HTTPS. 04:24.630 --> 04:35.630 So if I was out and using open Wi-Fi, I would use an SSH server that I was running and tunnel all of my traffic through there. 04:35.870 --> 04:41.230 And this diagram just gives a basic overview of what that does. 04:41.230 --> 04:49.990 But the idea is I use SSH, which is an encrypted protocol, as a tunnel for all the rest of my web traffic. 04:50.930 --> 05:02.130 And by default, most browsers will tunnel the main HTTP traffic, but it doesn't always tunnel the DNS traffic. 05:02.130 --> 05:09.570 So ultimately, the SOCKS proxy will tunnel it to the remote server over SSH. 05:09.570 --> 05:15.050 And then from there, it all gets sent as if you were local there. 05:15.050 --> 05:20.890 So whether it was any traffic that is encrypted or plain text gets sent from that location. 05:20.890 --> 05:36.750 So the idea being that I don't trust my immediate Wi-Fi neighborhood, but I might have greater trust in the network area where the SSH server resides. 05:39.010 --> 05:47.070 As I mentioned, browsers don't necessarily, by default, tunnel DNS traffic over SOCKS proxies. 05:47.070 --> 05:53.150 However, in browsers like Firefox, there's usually a setting that you can set. 05:53.150 --> 06:03.030 So in this case, if you go to about config, you'll get a little warning that making changes to these settings may be dangerous. 06:03.030 --> 06:13.790 But if you search for SOCKS remote DNS, you'll see that by default, this actual value is set to false, but you can set it to true. 06:13.790 --> 06:18.150 And then whenever you're using a SOCKS proxy, it gets sent over that. 06:18.150 --> 06:20.950 And if you're using SSH, it's all encrypted. 06:20.950 --> 06:26.550 So the only traffic that somebody over Wi-Fi will see is SSH traffic. 06:26.550 --> 06:32.570 And they won't even be able to tell if you're surfing the web or making any other DNS queries. 06:32.570 --> 06:35.510 It's all tunneled over SSH. 06:38.830 --> 06:42.070 The other alternative is to use a VPN. 06:42.290 --> 06:44.170 Many people use VPNs now. 06:44.970 --> 06:50.330 Corporations use VPNs for remote workers, which is especially common nowadays. 06:50.330 --> 06:59.570 And that just tunnels all traffic from one machine over to another over an encrypted tunnel. 06:59.570 --> 07:06.990 Similar to the SSH setup, however, with the SSH SOCKS proxy, that was primarily web traffic. 07:06.990 --> 07:13.270 Other network connections could be sent over the local network. 07:13.310 --> 07:18.990 And in that case, those DNS queries could be leaked out. 07:20.910 --> 07:25.550 But it requires a little bit more infrastructure to set up a VPN. 07:26.710 --> 07:31.830 Many Linux servers, Linux machines have SSH just installed by default. 07:31.830 --> 07:41.150 So it's simpler if you have a home machine, you could do the SSH SOCKS proxying without having to set up a VPN. 07:44.110 --> 07:53.150 And then the next consideration I had, and this is something that I played around with, but many of you are maybe familiar with Tor. 07:53.650 --> 07:57.270 And this just gives a brief overview of how Tor works. 07:57.770 --> 08:12.230 Tor basically encrypts your communication through multiple hops, so that your client and the first entry node into the Tor network know about each other. 08:12.230 --> 08:14.730 And that node knows about the next node. 08:15.030 --> 08:18.730 And then that next node knows about the exit node. 08:18.730 --> 08:24.950 But each node doesn't know about ones outside of the ones that they're communicating with. 08:24.950 --> 08:27.690 And each level is encrypted. 08:28.090 --> 08:36.090 Now, Tor only works with TCP traffic, and DNS is a UDP protocol. 08:36.770 --> 08:39.710 And we're not going to worry too much about the details of that. 08:39.710 --> 08:55.010 But typically, Tor clients will actually, underlying, it's using a SOCKS proxy, and it will just manually, forward that host name all the way to the exit relay. 08:55.010 --> 09:07.070 And then the exit relay will make the DNS request, and then forward that back to the client for the final TCP connection. 09:08.790 --> 09:26.430 So this provides perhaps even more protection than the others, because it disassociates the client with the DNS in a more obfuscated way. 09:26.430 --> 09:39.230 However, there are network analysis attacks that could correlate the query, the traffic from the client, including the DNS queries, back to the exit node. 09:43.890 --> 09:47.130 So now we'll talk about encrypted DNS protocols. 09:47.130 --> 10:02.690 So in this case, we're going to have modified DNS protocols that will encrypt the traffic to prevent eavesdropping and protect the confidentiality of their queries. 10:05.170 --> 10:09.990 The first one is DNS over HTTPS slash TLS. 10:09.990 --> 10:18.410 Now, many of you may know that HTTPS is just HTTP over TLS, so you might wonder what's the difference. 10:18.610 --> 10:39.710 Primarily, the main difference is that DNS over HTTPS uses port 443 and will look like regular HTTPS traffic to anyone who's observing it, whereas DNS over TLS uses its own dedicated port of 853. 10:39.790 --> 10:50.630 And there are pros and cons to using this protocol, the different protocols here, depending on your perspective. 10:50.630 --> 11:07.070 From a privacy perspective, DNS over HTTPS is generally the preferred one because you're not only hiding the DNS query, but you're also hiding the fact that you're making a DNS query by just making it look like it's a regular HTTPS traffic. 11:07.390 --> 11:21.150 For network administrators, though, they might want to know that DNS queries are being made so that they can potentially be blocked, and so DNS over TLS is generally preferred in that situation. 11:26.490 --> 11:46.750 Now, as I mentioned before, Tor, by default, has a mechanism to make, essentially, DNS queries on behalf of the client without you really tunneling the full DNS protocol over the Tor network. 11:46.750 --> 11:55.150 But there's also been work towards actually implementing a DNS protocol over Tor. 11:55.150 --> 11:58.470 That's something that Cloudflare has been doing. 11:58.470 --> 12:10.890 So Cloudflare also does the DNS over TLS, but they are also doing DNS over Tor. 12:10.890 --> 12:16.470 And so, briefly, how that's working is, first, using a hidden service. 12:16.470 --> 12:36.750 And just to briefly describe what hidden services are in Tor, basically, there is a rendezvous point in the middle of the Tor network, and the hidden service and the client essentially connect through that rendezvous point. 12:36.750 --> 12:41.190 So they don't actually know who's on either side of it. 12:41.190 --> 12:45.810 But it's so that all the traffic is living inside the Tor network. 12:46.150 --> 12:57.690 And, essentially, DNS over HTTPS or DNS over TLS can be tunneled through this hidden service. 12:57.690 --> 13:02.490 And that's one other service that Cloudflare provides. 13:06.880 --> 13:17.540 Now, this protocol that I read about and referred to earlier that came out a little over a year ago, it was called Oblivious DNS. 13:17.540 --> 13:25.260 And this takes a bit of a different take on how to protect the privacy of clients. 13:25.260 --> 13:30.060 So this diagram goes over the basic protocol. 13:30.060 --> 13:32.880 And I'll just talk through how it works. 13:32.880 --> 13:39.640 So the client would have an ODNS stub running on their machine. 13:39.720 --> 13:46.860 And it would talk to a DNS recursive server. 13:47.800 --> 13:58.880 And what it would... what the ODNS stub will do is create a session key and encrypt the DNS name. 13:59.500 --> 14:06.920 And then append the .odns top-level domain to the domain name. 14:06.920 --> 14:08.600 So the encrypt... 14:08.600 --> 14:13.180 the domain name gets encrypted, but will then act as like a regular domain name. 14:13.440 --> 14:14.400 And then 14:17.880 --> 14:28.520 the authoritative ODNS server will have a public key, which will be used by the ODNS stub to encrypt the session key. 14:28.840 --> 14:35.160 And that gets sent along with additional information in the additional information section of the DNS request. 14:35.160 --> 14:46.860 That gets forwarded onto the recursive DNS server, which then sends that off to the authoritative ODNS server. 14:46.860 --> 14:58.200 So what this does is it hides the query from the recursive DNS server that you can see right after the stub. 14:58.200 --> 15:03.800 So this server here can't tell what host the client is looking for. 15:03.880 --> 15:09.700 And over here, it can't tell where that request came from. 15:09.700 --> 15:23.580 So even though it will decrypt the session key and then decrypt the original host name that the client was looking for, all it knows is it came from this recursive server and not from the client. 15:24.740 --> 15:28.140 And then from there, it acts as a regular DNS server. 15:30.180 --> 15:40.480 Now in the actual implementation, they have it fall back to regular DNS if the ODNS stub doesn't work. 15:41.120 --> 15:50.360 And in the paper, they get into more details about how to manage load balancing of the DNS servers. 15:50.360 --> 16:10.440 But the basic idea is to hide the information from this server so that if anybody were able to compromise the recursive server, they wouldn't be able to tell what hosts the client was looking for. 16:10.500 --> 16:17.740 And on this end, on the authoritative ODNS server, you wouldn't be able to know which clients were making the requests in the first place. 16:17.740 --> 16:39.680 And this differs from the DNS over HTTPS and DNS over TLS standard setups because even though that preserves privacy from an eavesdropper on the network, someone could still gain access to the DNS server and it could be logged who made which request. 16:41.220 --> 16:50.680 So if this was through a government request or somebody hacked the server and dumped logs, you're still vulnerable. 16:50.680 --> 16:59.580 Or even if it wasn't logged, a hacker could then monitor what's going on that DNS server. 16:59.640 --> 17:07.140 So it will compromise the privacy of everybody who uses that server, whether it's over TLS or not. 17:07.480 --> 17:17.120 And this way, it keeps information separate and makes it harder to correlate. 17:17.420 --> 17:32.920 I will say that the DNS over Tor seems to accomplish a similar task, but I think this was a very interesting solution to the problem. 17:33.880 --> 17:40.700 And I just will include here for a moment and just reiterate the basic process. 17:40.700 --> 17:47.660 So when you are going to make a DNS request, you first generate a session key. 17:47.980 --> 17:50.740 And hopefully this makes it a little more clear. 17:50.740 --> 17:53.840 You encrypt the domain name. 17:53.840 --> 18:05.020 And so that's what the brackets are indicating is that the original domain name, in this case foo.com, is being encrypted with the session key K. 18:05.020 --> 18:11.440 And then it's appended with the ODNS top level domain. 18:11.480 --> 18:19.860 And then the session key is encrypted with the ODNS authoritative server's public key. 18:19.920 --> 18:24.500 And it's included in the additional information section in the DNS request. 18:24.900 --> 18:34.940 So that it essentially looks like regular DNS traffic, but it's still encrypted and preserves that privacy. 18:35.980 --> 18:39.140 And makes for an easy fallback to regular DNS. 18:42.200 --> 18:57.180 So after seeing this, and it was because when I first saw the title of Oblivious DNS, it made me think of a particular cryptographic primitive that I learned about 10 years ago called Oblivious Transfer. 18:57.180 --> 19:00.040 And that was actually initially what I thought it was going to involve. 19:00.200 --> 19:01.300 And it didn't. 19:01.300 --> 19:12.760 But it got me to thinking that perhaps one could combine these two just to add an additional layer of potential privacy. 19:12.760 --> 19:45.460 So the concern I have is that actually if we go back and look at the diagram of the Oblivious DNS setup, if one had enough network visibility, they could potentially see traffic going from the ODNS stub to the DNS, recursive DNS server, and then from there to the authoritative server and then help found there. 19:45.460 --> 19:49.660 That'd be a lot of network visibility, but it's conceivable. 19:49.760 --> 19:59.580 And so there could be correlations between the DNS requests made by the authoritative server and the requests coming from the clients. 19:59.580 --> 20:23.080 So it got me thinking, what if the authoritative ODNS server cast results like most DNS servers do, and these would have to be invalidated after a timeout as, again, as regular DNS servers do, but they could store it in what's called an encrypted distributed hash table. 20:23.260 --> 20:34.760 And so that I can talk about how one could essentially query the authoritative server. 20:34.760 --> 20:36.460 And this is very high level. 20:36.460 --> 20:39.840 I don't have a fully worked out protocol, but just something to think about. 20:39.840 --> 20:51.300 But they could query the authoritative server to see if it already knows the host that it's for without revealing what that host is. 20:51.420 --> 21:08.820 And then if it already knows it, it can get that IP address, again, without revealing additional IP addresses from the DNS server and revealing which host to the DNS server the client is looking for. 21:08.820 --> 21:12.080 So that involves a couple of things first. 21:12.080 --> 21:18.400 So with a hash table, you have a key that you need to search for. 21:19.140 --> 21:23.220 And so you need some way of searching text. 21:24.140 --> 21:29.560 And you can use additively homomorphic encryption to do this. 21:29.960 --> 21:35.780 And I'll describe actually in a plain text version of the protocol first how that works. 21:35.780 --> 21:55.500 And then you can see how if I'll briefly explain additively homomorphic encryption, and you can see how this technique would allow you to send an encrypted query to search the hash table to see if the key exists. 21:55.500 --> 21:59.820 And then we'll talk about blues transfer and how to actually get the value out of it. 21:59.820 --> 22:16.680 So this protocol was developed actually for, well, as a modification of a neural network protocol or method to do text pattern matching. 22:16.680 --> 22:24.960 And it was developed as a way of creating an encrypted text pattern match protocol. 22:24.960 --> 22:28.060 And the way it works is that you have some alphabet. 22:28.060 --> 22:38.200 In the original technique, it was... in the original protocol, they were concerned with potentially searching for DNA sequence patterns. 22:38.200 --> 22:42.720 So you'll see the alpha that here is A, C, G, and T. 22:43.520 --> 22:51.620 And what you do is you have what you call a character delay vector. 22:51.620 --> 23:20.320 So for each letter in the alphabet, you say, okay, the idea is assuming as we're moving through the text that we're searching, if at this point from here on out, we're going to match the pattern, how much further should we go in order to say that we're at the end of the... what we mean so that it's at the end of the pattern. 23:20.320 --> 23:22.680 A little complicated, but we'll look at this example here. 23:22.680 --> 23:27.340 So the pattern here is TACT, T-A-C-T. 23:27.420 --> 23:30.320 And the first letter is A. 23:30.380 --> 23:43.960 So if that... if the A that we find is in this... is part of this pattern, then two letters later, we'll be at the end of the pattern. 23:43.960 --> 23:45.460 So we'll put a one there. 23:47.060 --> 23:56.200 If... or for the next letter, C, if we find a C, then there's only one letter later that we need to go to get to the end of the pattern. 23:56.920 --> 24:03.540 There are no Gs, so if we find a G, we're not in that pattern at all. 24:03.620 --> 24:06.280 And for T, there's actually two possibilities. 24:06.280 --> 24:15.480 We could be at the beginning of the pattern, in which case you'd put a one at the end of this little vector. 24:17.100 --> 24:23.460 Or we could be at the... so if it's the T at the beginning, we put a one at the end of the vector. 24:23.480 --> 24:30.180 And if it's the T from the beginning... sorry, T from the end, then we put a one at the beginning of the vector. 24:30.260 --> 24:34.320 So you'll see this one, zero, zero, one vector. 24:34.440 --> 24:39.080 The ones correspond to the opposite Ts from the original pattern. 24:39.080 --> 24:47.420 And this diagram basically shows how this text pattern matching algorithm works. 24:47.420 --> 25:06.260 You start off with a vector of all zeros, and then through each letter in the text you're searching, you go through... you get the corresponding vector from the pattern you're searching, and you just add shifting one over as you go. 25:06.680 --> 25:12.720 So with G being the first letter, those all zeros, we add that, the vector remains unchanged. 25:12.960 --> 25:27.200 We take the next letter A, and we add this vector one, zero, zero, one, zero, and we get... we update the activation vector, as it's called, and so on and so forth. 25:27.200 --> 25:37.120 And you'll see that at the end, because the pattern is there, there is a four, because that's the length of the pattern. 25:37.760 --> 25:51.500 And the idea is that when you have the entire pattern, those ones all will add up in the same spot to the whole length of the pattern you're looking for. 25:54.140 --> 26:02.120 And so, basically, you just look for the number four, and you might say, okay, the pattern was found. 26:02.860 --> 26:07.720 Now, as I mentioned, we want to do this in encrypted fashion. 26:07.920 --> 26:22.680 It turns out there are some cryptographic algorithms that allow you to perform an operation that will give you the ciphertext of the sum of the plaintext. 26:22.680 --> 26:32.460 So, if you have an encryption of zero and an encryption of one, you can do an operation, and you'll get, well, in that case, the encryption of one as well. 26:32.460 --> 26:42.300 Or, if you have an encryption of one and another encryption of one, and you perform an operation, you'll get something that will be equivalent to the encryption of two. 26:42.300 --> 26:47.540 In other words, if you decrypt that value, run it through the decryption algorithm, you'll get out two. 26:48.180 --> 26:49.620 So on and so forth. 26:50.540 --> 27:06.540 So, the idea here is that you would encrypt these values, so you'd have an encryption of zero, an encryption of zero, an encryption of one, an encryption of zero for A, similarly for C, G, and T. 27:06.960 --> 27:19.660 And then you can do the same addition, as we see here, and you'll end up with a vector that will have a value that's an encryption of four. 27:19.660 --> 27:29.900 Now, one nice trick is that you can essentially subtract the encryption of the pattern length from the entire vector. 27:30.120 --> 27:35.420 And then, instead of looking for the length of the pattern, you're going to look for zero. 27:35.420 --> 27:50.340 And this is useful because there are some algorithms, some ciphers, that while they do perform this homomorphic operation, it's actually hard to really decrypt them. 27:51.020 --> 28:02.120 One example is using elliptic curves, where the encryption of a number M is M times a base point. 28:02.120 --> 28:04.560 I won't get into too many details about that. 28:05.200 --> 28:17.660 But for those who are familiar with elliptic curves, you can see that that's additively homomorphic, but based on the security of the cipher, actually finding out what that M is from a given point is hard. 28:17.660 --> 28:24.500 But if you're actually looking for zero, you know that's going to be the identity, and that's easy to identify. 28:24.500 --> 28:34.620 So that's basically how you can do this search in the key space of the hash table. 28:36.120 --> 28:47.580 And then, once you know if the host name is in the cache of the Oblivious DNS server, then you want to actually retrieve it. 28:47.580 --> 28:51.070 And here we'll use a technique called Oblivious Transfer. 28:51.630 --> 29:02.130 And basically what this is, is we have an index into the... so maybe we find out that it was the fifth host that was in the list. 29:02.590 --> 29:11.810 Then we can essentially request the fifth entry without revealing that we're actually asking for that one. 29:11.830 --> 29:23.610 And the DNS server will send us back data that will only give us information about the fifth one and not any of the other IPs for the other hosts. 29:24.650 --> 29:33.830 Now, I will admit that Oblivious Transfer actually has a fairly high bandwidth, so requires a lot of data transfer. 29:34.130 --> 29:39.030 But that's something that could be considered for the future. 29:41.450 --> 29:56.090 And just want to end with some references for the actual... above is the actual paper that started this idea for this talk, the Oblivious DNS paper. 29:56.090 --> 30:04.510 And then a couple links to Cloudflare that just talks about the DNS over HTTPS and DNS over TOR. 30:06.570 --> 30:11.410 So with that, I look forward to answering any questions. 30:11.590 --> 30:12.690 Thank you. 30:43.670 --> 30:47.210 Hi Matt, what a fantastic talk. 30:47.210 --> 30:53.290 Thank you so much for speaking this year again at the Crypto Privacy Village as a longtime volunteer. 30:53.370 --> 30:55.350 It's always great to have you back. 30:56.170 --> 31:01.470 I am pulling up some questions here from the Discord. 31:01.670 --> 31:03.730 Oh yeah, I see that one coming through. 31:03.730 --> 31:04.990 So there's a question. 31:04.990 --> 31:07.470 Do you mind if I... Oh yeah, go ahead. 31:07.470 --> 31:09.070 Go ahead, please take it. 31:09.070 --> 31:13.270 Yeah, so I see that somebody's asking, are there any implementations of ODNS? 31:13.490 --> 31:23.850 If I recall correctly from the paper which I referenced in the reference slide, they do refer to a Go implementation, I believe. 31:23.850 --> 31:25.470 So they do have one. 31:25.470 --> 31:27.850 I actually mean to check it out, but I haven't got around to it. 31:28.230 --> 31:37.910 But yeah, if you grab the link off the slide deck or if you just search for ODNS or Oblivious DNS, it shouldn't be hard to find. 31:39.070 --> 31:50.890 And the one thing that occurred to me when thinking about playing with this is, well, if I don't have more than one person using the same server, then it semi-defeats the purpose. 31:50.890 --> 32:01.630 Because part of the point is to have multiple people connecting to the same ODNS server and making it difficult to track which one made which request. 32:01.750 --> 32:08.870 But yeah, that's something I've been thinking about playing around with myself. 32:10.850 --> 32:11.770 Fantastic. 32:12.690 --> 32:15.590 Does anyone have any more questions for Matt? 32:15.590 --> 32:18.510 You can drop them into the Discord. 32:24.320 --> 32:25.600 People are typing. 32:30.950 --> 32:38.270 Yeah, I figured it wasn't like a super technical talk, so there might not be a ton of questions, but just something that I came across last year. 32:38.270 --> 32:39.590 I was like, this sounds interesting. 32:39.590 --> 32:45.690 I want to read up on it and figured this would be a good way to force myself to actually read the paper. 32:46.430 --> 32:48.590 We have another question that just came in. 32:48.590 --> 32:52.830 Are there specific foreseeable problems with ODNS? 32:53.510 --> 32:55.210 Oh, that's a good question. 32:56.130 --> 32:59.790 So, not necessarily that I can think of. 32:59.790 --> 33:05.190 So, one of the things I've been thinking about is comparing ODNS versus some of the other options. 33:06.670 --> 33:18.110 One of the... like, I think the only other option that provides similar levels of privacy was the DNS over Tor. 33:18.350 --> 33:22.790 So, doing DNS over HTTPS over a hidden service in Tor. 33:23.430 --> 33:27.730 But one of the problems with that is that people can see they're using Tor. 33:28.230 --> 33:33.090 So, as I understand the way the ODNS works, it more or less looks like regular DNS traffic. 33:33.090 --> 33:39.530 If you do look at it closely enough, you can see the ODNS TLD, which will somewhat flag that. 33:39.530 --> 33:42.310 But you have to look fairly hard. 33:42.930 --> 33:48.850 But other than that, I don't know of any other issues. 33:49.470 --> 33:52.190 But something to think about, certainly. 33:55.170 --> 33:56.230 Fantastic. 33:57.070 --> 34:01.250 I will... I'll throw a question at you, since I have you. 34:01.250 --> 34:05.890 And just to give anyone some extra time, if they have any additional questions. 34:06.730 --> 34:09.150 Are there any... you know, we're all virtual. 34:09.150 --> 34:10.990 I've heard there are, like, hundreds of talks. 34:10.990 --> 34:16.450 Are there any other talks that you're really looking forward to seeing during this DEF CON virtual weekend? 34:16.470 --> 34:17.990 That's a good question. 34:18.270 --> 34:22.430 So, there's actually one that I found out about yesterday. 34:22.590 --> 34:23.870 But it was actually earlier. 34:24.070 --> 34:32.510 So, and this is... I saw that Chris Weisoppel was doing a talk in the Red Team Village. 34:32.610 --> 34:34.490 So, I actually did check that out this morning. 34:35.390 --> 34:38.370 You know, partially because he's the founder of the company I work for. 34:38.410 --> 34:41.010 So , and I've got to know him a little bit. 34:41.010 --> 34:42.870 I was curious to see what he had to say. 34:43.350 --> 34:48.730 And we got to learn a little bit more about his history with Loft, which was pretty cool. 34:49.390 --> 34:59.070 Because I hear the stories about those days from Chris and Christian. 34:59.890 --> 35:02.430 But there was more interesting things. 35:02.430 --> 35:10.370 Like the... he was talking about pen testing his prospective employer, which was pretty interesting. 35:10.370 --> 35:21.450 Because he was, like... not many times do you get the opportunity to hack your future employer's voicemail and find out what they're actually thinking about your negotiations. 35:22.690 --> 35:25.150 Because apparently, they were asking for a sneakers van. 35:25.190 --> 35:26.870 Like, from the movie Sneakers. 35:26.870 --> 35:30.610 And they were, like, these guys want a Winnebago. 35:32.090 --> 35:34.950 I don't think they quite understood what the purpose of it was. 35:35.670 --> 35:39.830 So, that was actually one that I found about and did get to check out. 35:40.150 --> 35:45.590 I've been kind of... blank on the word. 35:45.590 --> 35:48.270 But I haven't really been keeping up with all the entire schedule. 35:48.270 --> 35:49.690 So, I need to take a look at that. 35:50.350 --> 35:57.150 But of course, I also enjoyed the talks from the village... from this village so far today. 35:57.150 --> 36:02.430 Been watching the streams since 10 Pacific time. 36:02.950 --> 36:03.810 Fantastic. 36:03.810 --> 36:05.670 And look forward to the ones tomorrow, too. 36:05.670 --> 36:07.950 Yeah, I'm looking forward to all of them, too. 36:07.950 --> 36:16.170 And thankfully, everything is going to be available after the conference to download, to stream on various services. 36:16.170 --> 36:16.410 Oh! 36:16.410 --> 36:19.890 We have another question that just came in. 36:20.010 --> 36:24.390 Are there any practical implementations of ODNS yet? 36:24.390 --> 36:26.890 Or is this theoretical at this point? 36:27.510 --> 36:28.150 Yes. 36:28.890 --> 36:32.550 I'm not sure if you caught the... so, somebody else asked about an implementation. 36:32.630 --> 36:39.230 And so, as far as I know, there's a Golang implementation out there that the researchers used. 36:39.710 --> 36:42.590 And I believe it's on GitHub, but I don't remember. 36:42.590 --> 36:44.170 I could be remembering incorrectly. 36:44.570 --> 36:48.430 But it is referenced in their paper. 36:48.650 --> 36:56.370 So, if you caught that from my reference slide, or if you just Google for ODNS, you should be able to find their paper fairly easily. 36:57.030 --> 36:59.630 And I'll have links there, I think. 37:00.770 --> 37:01.590 Pretty sure. 37:02.130 --> 37:03.010 Fantastic. 37:03.810 --> 37:07.450 Well, thank you so much, again, for your time. 37:07.830 --> 37:12.210 And as always, for being a volunteer at the Fitzgerald Privacy Village. 37:12.210 --> 37:15.730 I look forward to seeing you, hopefully, in person next year. 37:15.730 --> 37:16.010 Yep. 37:16.010 --> 37:16.750 Hopefully. 37:17.030 --> 37:18.330 And all that other fun stuff. 37:18.330 --> 37:18.970 So, thanks again.