[00:02.000 --> 00:08.970]  Hi, I'm Matt Chung, and I want to talk today about DNS privacy. Now, usually with DNS,
[00:08.970 --> 00:16.410]  we hear about DNSSEC as in authenticating DNS queries. Here, I'm interested in a different
[00:16.410 --> 00:24.330]  aspect of DNS security, and that is the privacy of DNS queries to protect users from
[00:26.010 --> 00:31.290]  eavesdroppers finding out what sort of sites they're visiting if they are of sensitive nature.
[00:32.050 --> 00:39.090]  And I decided to talk about this topic after coming across a paper that I found about a year
[00:39.090 --> 00:46.530]  ago that talked about a novel approach to this problem. And so I decided to create this talk
[00:46.530 --> 00:53.690]  that goes over some of my experience with this topic over the years, leading up to this paper
[00:53.690 --> 01:01.560]  and some future thoughts about the topic. To begin with, I'm just going to do a brief
[01:01.560 --> 01:07.120]  introduction to DNS, just a very high-level introduction so that we know what we're
[01:07.120 --> 01:14.660]  talking about, and then we can talk about how we can preserve DNS privacy.
[01:16.500 --> 01:24.840]  So, at a very high level, DNS, or the domain name system, is a way of translating a host name
[01:24.840 --> 01:31.780]  into an IP address so we can find that on the internet. And basically, the way that works is
[01:31.780 --> 01:41.280]  when your client is trying to access a site on a host, then it first sends out that host name
[01:41.960 --> 01:49.000]  to its DNS server, which, if it doesn't know it, will try the root name server. And in this case,
[01:49.000 --> 01:55.700]  if they're looking for www.wikipedia.org, it tries the root name server, and it says,
[01:55.700 --> 02:02.080]  well, I don't know where that is, but try the org name server. And the org name server may say,
[02:02.080 --> 02:08.240]  I don't know where that is, but try the wikipedia.org name server. And from there,
[02:08.240 --> 02:14.920]  that name server says, oh, I know, it's this IP address. So it has this hierarchical structure
[02:14.920 --> 02:24.890]  that it works through recursively. Now, the first aspect of DNS privacy that I'm going to talk about
[02:24.890 --> 02:32.390]  is what we sort of call local privacy. It's the first aspect that I considered in terms of my own
[02:32.390 --> 02:40.050]  personal threat model. And so we'll discuss what the challenge is and some solutions that can
[02:40.050 --> 02:54.630]  easily be undertaken. So the first situation is you might be browsing the web at a cafe using open
[02:54.630 --> 03:04.110]  Wi-Fi. 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:18.990]  Here, we're seeing a DNS query for google.com. And it would be very simple for somebody with
[03:19.630 --> 03:26.970]  a laptop and Wi-Fi card to sniff traffic like this on open Wi-Fi at a coffee shop. So
[03:29.170 --> 03:35.430]  as you can see, it's all plain text. In this case, looking at google.com,
[03:35.430 --> 03:41.570]  it's generally not considered a purely sensitive post. But if you're looking up information about
[03:41.790 --> 03:49.190]  a health condition or any other issue that you don't want to... or other information that you
[03:49.190 --> 03:55.250]  don't want people to know that you're looking up for the reason if it's not considered socially
[03:55.250 --> 04:02.730]  acceptable, you don't want people to just be able to sniff that information over Wi-Fi.
[04:02.730 --> 04:11.690]  So the first solution that I considered over the years was to tunnel DNS over SOCKS proxies. So
[04:12.870 --> 04:18.550]  first, I just wanted to make sure that all traffic was being encrypted, especially
[04:19.550 --> 04:29.510]  10 plus years ago, not every site was using HTTPS. So if I was out and using open Wi-Fi,
[04:29.510 --> 04:35.630]  I would use an SSH server that I was running and tunnel all of my traffic through there.
[04:35.870 --> 04:44.250]  And this diagram just gives a basic overview of what that does. But the idea is I use SSH,
[04:44.250 --> 04:52.810]  which is an encrypted protocol, as a tunnel for all the rest of my web traffic. And by default,
[04:52.810 --> 05:02.130]  most browsers will tunnel the main HTTP traffic, but it doesn't always tunnel the DNS traffic.
[05:02.130 --> 05:10.530]  So ultimately, the SOCKS proxy will tunnel it to the remote server over SSH. And then from there,
[05:10.530 --> 05:18.050]  it all gets sent as if you were local there. So whether it was any traffic that is encrypted or
[05:18.050 --> 05:26.710]  plain text gets sent from that location. So the idea being that I don't trust my immediate Wi-Fi
[05:26.710 --> 05:36.750]  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:54.570]  However, in browsers like Firefox, there's usually a setting that you can set. So in this case,
[05:54.570 --> 06:01.010]  if you go to about config, you'll get a little warning that making changes to these settings
[06:01.750 --> 06:09.990]  may be dangerous. But if you search for SOCKS remote DNS, you'll see that by default,
[06:09.990 --> 06:15.010]  this actual value is set to false, but you can set it to true. And then whenever you're using
[06:15.150 --> 06:21.110]  a SOCKS proxy, it gets sent over that. And if you're using SSH, it's all encrypted. So
[06:21.690 --> 06:27.110]  the only traffic that somebody over Wi-Fi will see is SSH traffic. And they won't even be able
[06:27.110 --> 06:35.510]  to tell if you're surfing the web or making any other DNS queries. It's all tunneled over SSH.
[06:38.830 --> 06:46.550]  The other alternative is to use a VPN. Many people use VPNs now. Corporations use VPNs for
[06:46.550 --> 06:53.070]  remote workers, which is especially common nowadays. And that just tunnels all traffic
[06:53.670 --> 07:01.710]  from one machine over to another over an encrypted tunnel. Similar to the SSH setup,
[07:01.710 --> 07:08.390]  however, with the SSH SOCKS proxy, that was primarily web traffic. Other network connections
[07:09.080 --> 07:18.990]  could be sent over the local network. And in that case, those DNS queries could be leaked out.
[07:20.910 --> 07:28.890]  But it requires a little bit more infrastructure to set up a VPN. Many Linux servers, Linux machines
[07:28.890 --> 07:34.870]  have SSH just installed by default. So it's simpler if you have a home machine, you could
[07:34.870 --> 07:47.630]  do the SSH SOCKS proxying without having to set up a VPN. And then the next consideration I had,
[07:47.630 --> 07:53.150]  and this is something that I played around with, but many of you are maybe familiar with Tor.
[07:53.650 --> 08:01.930]  And this just gives a brief overview of how Tor works. Tor basically encrypts your communication
[08:02.750 --> 08:10.650]  through multiple hops, so that your client and the first entry node into the Tor network
[08:10.650 --> 08:17.070]  know about each other. And that node knows about the next node. And then that next node
[08:17.070 --> 08:23.530]  knows about the exit node. But each node doesn't know about ones outside of the ones that they're
[08:23.530 --> 08:33.410]  communicating with. And each level is encrypted. Now, Tor only works with TCP traffic, and DNS is
[08:33.930 --> 08:40.770]  a UDP protocol. And we're not going to worry too much about the details of that. But typically,
[08:40.770 --> 08:50.950]  Tor clients will actually, underlying, it's using a SOCKS proxy, and it will just manually,
[08:50.950 --> 08:57.070]  forward that host name all the way to the exit relay. And then the exit relay will make the
[08:57.070 --> 09:07.070]  DNS request, and then forward that back to the client for the final TCP connection.
[09:08.790 --> 09:15.490]  So this provides perhaps even more protection than the others, because
[09:17.670 --> 09:27.470]  it disassociates the client with the DNS in a more obfuscated way. However, there are
[09:28.240 --> 09:35.430]  network analysis attacks that could correlate the query, the traffic from the client,
[09:35.430 --> 09:47.130]  including the DNS queries, back to the exit node. So now we'll talk about encrypted DNS protocols.
[09:47.130 --> 09:54.410]  So in this case, we're going to have modified DNS protocols that will encrypt the traffic
[09:54.410 --> 10:02.690]  to prevent eavesdropping and protect the confidentiality of their queries.
[10:05.170 --> 10:14.510]  The first one is DNS over HTTPS slash TLS. Now, many of you may know that HTTPS is just HTTP
[10:14.510 --> 10:22.460]  over TLS, so you might wonder what's the difference. Primarily, the main difference is that
[10:23.470 --> 10:32.190]  DNS over HTTPS uses port 443 and will look like regular HTTPS traffic to anyone who's observing
[10:32.190 --> 10:42.790]  it, whereas DNS over TLS uses its own dedicated port of 853. And there are pros and cons to
[10:43.590 --> 10:51.330]  using this protocol, the different protocols here, depending on your perspective. From a privacy
[10:51.330 --> 10:58.790]  perspective, DNS over HTTPS is generally the preferred one because you're not only hiding
[10:58.790 --> 11:03.470]  the DNS query, but you're also hiding the fact that you're making a DNS query by just making
[11:03.470 --> 11:09.790]  it look like it's a regular HTTPS traffic. For network administrators, though, they might want
[11:09.790 --> 11:17.890]  to know that DNS queries are being made so that they can potentially be blocked, and so DNS over
[11:17.890 --> 11:31.690]  TLS is generally preferred in that situation. Now, as I mentioned before, Tor, by default,
[11:33.190 --> 11:40.890]  has a mechanism to make, essentially, DNS queries on behalf of the client
[11:40.890 --> 11:48.090]  without you really tunneling the full DNS protocol over the Tor network. But there's also
[11:48.780 --> 11:56.090]  been work towards actually implementing a DNS protocol over Tor. That's something that
[11:56.090 --> 12:06.890]  Cloudflare has been doing. So Cloudflare also does the DNS over TLS, but they
[12:06.890 --> 12:16.470]  are also doing DNS over Tor. And so, briefly, how that's working is, first, using a hidden service.
[12:16.470 --> 12:25.270]  And just to briefly describe what hidden services are in Tor, basically, there is a rendezvous point
[12:25.270 --> 12:32.610]  in the middle of the Tor network, and the hidden service and the client
[12:33.570 --> 12:40.130]  essentially connect through that rendezvous point. So they don't actually know who's on either side
[12:40.130 --> 12:49.810]  of it. But it's so that all the traffic is living inside the Tor network. And, essentially, DNS over
[12:51.530 --> 12:58.970]  HTTPS or DNS over TLS can be tunneled through this hidden service. And that's one other
[12:58.970 --> 13:11.960]  service that Cloudflare provides. Now, this protocol that I read about and referred to earlier
[13:12.900 --> 13:20.360]  that came out a little over a year ago, it was called Oblivious DNS. And this takes a bit of a
[13:20.360 --> 13:29.180]  different take on how to protect the privacy of clients. So this diagram goes over the basic
[13:29.180 --> 13:37.740]  protocol. And I'll just talk through how it works. So the client would have an ODNS stub
[13:37.740 --> 13:47.820]  running on their machine. And it would talk to a DNS recursive server. And
[13:50.750 --> 13:57.660]  what it would... what the ODNS stub will do is create a session key and encrypt the DNS
[13:57.660 --> 14:08.600]  name. And then append the .odns top-level domain to the domain name. So the encrypt...
[14:08.600 --> 14:14.400]  the domain name gets encrypted, but will then act as like a regular domain name. And then
[14:17.880 --> 14:25.240]  the authoritative ODNS server will have a public key, which will be used by the ODNS
[14:25.240 --> 14:31.300]  stub to encrypt the session key. And that gets sent along with additional information in the
[14:31.300 --> 14:40.120]  additional information section of the DNS request. That gets forwarded onto the recursive DNS server,
[14:40.120 --> 14:49.920]  which then sends that off to the authoritative ODNS server. So what this does is it hides
[14:49.920 --> 14:58.200]  the query from the recursive DNS server that you can see right after the stub.
[14:58.200 --> 15:05.300]  So this server here can't tell what host the client is looking for. And over here,
[15:06.060 --> 15:12.800]  it can't tell where that request came from. So even though it will decrypt the session key and
[15:12.800 --> 15:18.820]  then decrypt the original host name that the client was looking for, all it knows is it came
[15:18.820 --> 15:26.800]  from this recursive server and not from the client. And then from there, it acts as a regular
[15:26.800 --> 15:38.900]  DNS server. Now in the actual implementation, they have it fall back to regular DNS if the ODNS stub
[15:38.900 --> 15:44.200]  doesn't work. And in the paper, they get into more details about
[15:45.880 --> 15:55.680]  how to manage load balancing of the DNS servers. But the basic idea is to hide
[15:56.780 --> 16:04.980]  the information from this server so that if anybody were able to compromise the recursive
[16:04.980 --> 16:11.760]  server, they wouldn't be able to tell what hosts the client was looking for. And on this end,
[16:11.760 --> 16:16.340]  on the authoritative ODNS server, you wouldn't be able to know which clients were making the
[16:16.340 --> 16:25.300]  requests in the first place. And this differs from the DNS over HTTPS and DNS over TLS standard
[16:25.300 --> 16:31.760]  setups because even though that preserves privacy from an eavesdropper on the network,
[16:31.760 --> 16:39.680]  someone could still gain access to the DNS server and it could be logged who made which request.
[16:41.220 --> 16:49.160]  So if this was through a government request or somebody hacked the server and dumped logs,
[16:49.160 --> 16:56.920]  you're still vulnerable. Or even if it wasn't logged, a hacker could then monitor what's going
[16:56.920 --> 17:02.940]  on that DNS server. So it will compromise the privacy of everybody who uses
[17:03.480 --> 17:14.340]  that server, whether it's over TLS or not. And this way, it keeps information separate
[17:15.100 --> 17:24.760]  and makes it harder to correlate. I will say that the DNS over Tor seems to accomplish a similar task,
[17:24.760 --> 17:36.180]  but I think this was a very interesting solution to the problem. And I just will include here
[17:36.180 --> 17:45.460]  for a moment and just reiterate the basic process. So when you are going to make a DNS request,
[17:45.460 --> 17:51.700]  you first generate a session key. And hopefully this makes it a little more clear. You encrypt
[17:51.700 --> 17:58.540]  the domain name. And so that's what the brackets are indicating is that the original domain name,
[17:58.540 --> 18:07.940]  in this case foo.com, is being encrypted with the session key K. And then it's appended with
[18:07.940 --> 18:17.220]  the ODNS top level domain. And then the session key is encrypted with the ODNS authoritative
[18:17.220 --> 18:24.500]  server's public key. And it's included in the additional information section in the DNS request.
[18:24.900 --> 18:33.500]  So that it essentially looks like regular DNS traffic, but it's still encrypted and preserves
[18:33.500 --> 18:45.000]  that privacy. And makes for an easy fallback to regular DNS. So after seeing this, and it was
[18:45.000 --> 18:52.060]  because when I first saw the title of Oblivious DNS, it made me think of a particular cryptographic
[18:52.060 --> 18:57.680]  primitive that I learned about 10 years ago called Oblivious Transfer. And that was actually
[18:57.680 --> 19:03.160]  initially what I thought it was going to involve. And it didn't. But it got me to thinking that
[19:03.160 --> 19:12.760]  perhaps one could combine these two just to add an additional layer of potential privacy.
[19:12.760 --> 19:19.740]  So the concern I have is that actually if we go back and look at
[19:21.560 --> 19:31.020]  the diagram of the Oblivious DNS setup, if one had enough network visibility,
[19:31.020 --> 19:38.900]  they could potentially see traffic going from the ODNS stub to the DNS, recursive DNS server,
[19:38.900 --> 19:46.140]  and then from there to the authoritative server and then help found there. That'd be a lot of
[19:46.140 --> 19:52.260]  network visibility, but it's conceivable. And so there could be correlations between
[19:52.260 --> 19:59.580]  the DNS requests made by the authoritative server and the requests coming from the clients.
[19:59.580 --> 20:11.020]  So it got me thinking, what if the authoritative ODNS server cast results like most DNS servers do,
[20:11.020 --> 20:17.540]  and these would have to be invalidated after a timeout as, again, as regular DNS servers do,
[20:17.540 --> 20:24.720]  but they could store it in what's called an encrypted distributed hash table. And so that
[20:24.720 --> 20:35.200]  I can talk about how one could essentially query the authoritative server. And this is
[20:35.200 --> 20:39.840]  very high level. I don't have a fully worked out protocol, but just something to think about.
[20:39.840 --> 20:47.660]  But they could query the authoritative server to see if it already knows the host that it's
[20:47.660 --> 20:57.220]  for without revealing what that host is. And then if it already knows it, it can get that
[20:57.220 --> 21:05.260]  IP address, again, without revealing additional IP addresses from the DNS server and revealing
[21:05.260 --> 21:12.080]  which host to the DNS server the client is looking for. So that involves a couple of things first.
[21:12.080 --> 21:21.800]  So with a hash table, you have a key that you need to search for. And so you need some way of
[21:21.800 --> 21:30.260]  searching text. And you can use additively homomorphic encryption to do this. And I'll
[21:30.260 --> 21:36.220]  describe actually in a plain text version of the protocol first how that works. And then
[21:38.060 --> 21:44.900]  you can see how if I'll briefly explain additively homomorphic encryption, and you
[21:44.900 --> 21:53.240]  can see how this technique would allow you to send an encrypted query to search the hash table
[21:53.240 --> 21:57.960]  to see if the key exists. And then we'll talk about blues transfer and how to actually get the
[21:57.960 --> 22:07.800]  value out of it. So this protocol was developed actually for, well, as a modification
[22:08.680 --> 22:18.380]  of a neural network protocol or method to do text pattern matching. And it was developed
[22:19.300 --> 22:26.720]  as a way of creating an encrypted text pattern match protocol. And the way it works is that you
[22:26.720 --> 22:33.600]  have some alphabet. In the original technique, it was... in the original protocol, they were
[22:33.600 --> 22:40.300]  concerned with potentially searching for DNA sequence patterns. So you'll see the alpha
[22:40.300 --> 22:51.620]  that here is A, C, G, and T. And what you do is you have what you call a character delay vector.
[22:51.620 --> 23:01.040]  So for each letter in the alphabet, you say, okay, the idea is assuming as we're moving through
[23:01.040 --> 23:10.020]  the text that we're searching, if at this point from here on out, we're going to match the pattern,
[23:10.020 --> 23:18.460]  how much further should we go in order to say that we're at the end of the... what we mean so that
[23:18.460 --> 23:22.400]  it's at the end of the pattern. A little complicated, but we'll look at this example
[23:22.400 --> 23:32.420]  here. So the pattern here is TACT, T-A-C-T. And the first letter is A. So if that... if the A that
[23:32.420 --> 23:42.180]  we find is in this... is part of this pattern, then two letters later, we'll be at the end of
[23:42.940 --> 23:50.160]  the pattern. So we'll put a one there. If... or for the next letter, C, if we find a C,
[23:50.160 --> 23:56.200]  then there's only one letter later that we need to go to get to the end of the pattern.
[23:56.920 --> 24:04.760]  There are no Gs, so if we find a G, we're not in that pattern at all. And for T,
[24:04.760 --> 24:09.400]  there's actually two possibilities. We could be at the beginning of the pattern,
[24:09.400 --> 24:15.480]  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:29.360]  And if it's the T from the beginning... sorry, T from the end, then we put a one at the beginning
[24:29.360 --> 24:36.280]  of the vector. So you'll see this one, zero, zero, one vector. The ones correspond to the
[24:36.280 --> 24:43.300]  opposite Ts from the original pattern. And this diagram basically shows how
[24:44.290 --> 24:50.780]  this text pattern matching algorithm works. You start off with a vector of all zeros, and then
[24:52.430 --> 24:58.700]  through each letter in the text you're searching, you go through... you get the
[24:58.700 --> 25:04.640]  corresponding vector from the pattern you're searching, and you just add shifting one over
[25:04.640 --> 25:12.720]  as you go. So with G being the first letter, those all zeros, we add that, the vector remains unchanged.
[25:12.960 --> 25:22.900]  We take the next letter A, and we add this vector one, zero, zero, one, zero, and we get... we update the
[25:22.900 --> 25:30.240]  activation vector, as it's called, and so on and so forth. And you'll see that at the end,
[25:30.240 --> 25:37.120]  because the pattern is there, there is a four, because that's the length of the pattern.
[25:37.760 --> 25:47.080]  And the idea is that when you have the entire pattern, those ones all will add up in the same spot
[25:47.920 --> 25:51.500]  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:10.660]  Now, as I mentioned, we want to do this in encrypted fashion. It turns out there are some
[26:10.660 --> 26:18.360]  cryptographic algorithms that allow you to perform an operation that will give you the
[26:19.360 --> 26:27.580]  ciphertext of the sum of the plaintext. So, if you have an encryption of zero and an encryption of one,
[26:27.580 --> 26:32.800]  you can do an operation, and you'll get, well, in that case, the encryption of one as well. Or,
[26:32.800 --> 26:37.200]  if you have an encryption of one and another encryption of one, and you perform an operation,
[26:37.200 --> 26:42.820]  you'll get something that will be equivalent to the encryption of two. In other words,
[26:42.820 --> 26:47.540]  if you decrypt that value, run it through the decryption algorithm, you'll get out two.
[26:48.180 --> 26:55.780]  So on and so forth. So, the idea here is that you would encrypt these values, so you'd have
[26:55.780 --> 27:03.340]  an encryption of zero, an encryption of zero, an encryption of one, an encryption of zero for A,
[27:03.340 --> 27:11.860]  similarly for C, G, and T. And then you can do the same addition, as we see here,
[27:12.400 --> 27:19.660]  and you'll end up with a vector that will have a value that's an encryption of four.
[27:19.660 --> 27:27.900]  Now, one nice trick is that you can essentially subtract the encryption of the pattern length
[27:27.900 --> 27:34.060]  from the entire vector. And then, instead of looking for the length of the pattern,
[27:34.060 --> 27:39.500]  you're going to look for zero. And this is useful because there are some algorithms,
[27:39.500 --> 27:47.200]  some ciphers, that while they do perform this homomorphic operation, it's actually
[27:47.200 --> 27:56.260]  hard to really decrypt them. One example is using elliptic curves,
[27:56.780 --> 28:03.460]  where the encryption of a number M is M times a base point. I won't get into too many details
[28:03.460 --> 28:07.760]  about that. But for those who are familiar with elliptic curves, you can see that that's
[28:07.760 --> 28:15.340]  additively homomorphic, but based on the security of the cipher, actually finding out what that M
[28:15.340 --> 28:21.000]  is from a given point is hard. But if you're actually looking for zero, you know that's
[28:21.000 --> 28:29.540]  going to be the identity, and that's easy to identify. So that's basically how you can do this
[28:29.540 --> 28:34.620]  search in the key space of the hash table.
[28:36.120 --> 28:44.820]  And then, once you know if the host name is in the cache of the Oblivious DNS server,
[28:44.820 --> 28:51.070]  then you want to actually retrieve it. And here we'll use a technique called Oblivious Transfer.
[28:51.630 --> 28:59.170]  And basically what this is, is we have an index into the... so maybe we find out that it was the
[28:59.170 --> 29:08.850]  fifth host that was in the list. Then we can essentially request the fifth entry without
[29:08.850 --> 29:16.670]  revealing that we're actually asking for that one. And the DNS server will send us back data that
[29:17.470 --> 29:23.610]  will only give us information about the fifth one and not any of the other IPs for the other hosts.
[29:24.650 --> 29:31.170]  Now, I will admit that Oblivious Transfer actually has a fairly high bandwidth, so
[29:31.790 --> 29:39.030]  requires a lot of data transfer. But that's something that could be considered for the future.
[29:41.450 --> 29:51.010]  And just want to end with some references for the actual... above is the actual paper that
[29:51.010 --> 29:59.110]  started this idea for this talk, the Oblivious DNS paper. And then a couple links to Cloudflare
[29:59.110 --> 30:09.970]  that just talks about the DNS over HTTPS and DNS over TOR. So with that, I look forward to
[30:09.970 --> 30:48.650]  answering any questions. Thank you. Hi Matt, what a fantastic talk. Thank you so much for speaking
[30:49.250 --> 30:54.210]  this year again at the Crypto Privacy Village as a longtime volunteer. It's always great to
[30:54.210 --> 31:02.610]  have you back. I am pulling up some questions here from the Discord. Oh yeah, I see that one
[31:02.610 --> 31:09.070]  coming through. So there's a question. Do you mind if I... Oh yeah, go ahead. 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:20.390]  If I recall correctly from the paper which I referenced in the reference slide, they do refer
[31:20.390 --> 31:26.550]  to a Go implementation, I believe. So they do have one. I actually mean to check it out,
[31:26.550 --> 31:32.990]  but I haven't got around to it. But yeah, if you grab the link off the slide deck or
[31:32.990 --> 31:37.910]  if you just search for ODNS or Oblivious DNS, it shouldn't be hard to find.
[31:39.070 --> 31:44.210]  And the one thing that occurred to me when thinking about playing with this is, well,
[31:44.210 --> 31:50.890]  if I don't have more than one person using the same server, then it semi-defeats the purpose.
[31:50.890 --> 31:56.710]  Because part of the point is to have multiple people connecting to the same ODNS server and
[31:57.770 --> 32:06.310]  making it difficult to track which one made which request. But yeah, that's something I've
[32:06.310 --> 32:15.070]  been thinking about playing around with myself. Fantastic. Does anyone have any more questions
[32:15.070 --> 32:25.600]  for Matt? You can drop them into the Discord. People are typing.
[32:30.950 --> 32:34.770]  Yeah, I figured it wasn't like a super technical talk, so there might not be a ton of questions,
[32:34.770 --> 32:40.210]  but just something that I came across last year. I was like, this sounds interesting. I want to
[32:40.210 --> 32:45.690]  read up on it and figured this would be a good way to force myself to actually read the paper.
[32:46.430 --> 32:52.830]  We have another question that just came in. Are there specific foreseeable problems with ODNS?
[32:53.510 --> 33:00.010]  Oh, that's a good question. So, not necessarily that I can think of. So,
[33:00.010 --> 33:05.190]  one of the things I've been thinking about is comparing ODNS versus some of the other options.
[33:06.670 --> 33:15.470]  One of the... like, I think the only other option that provides similar levels of privacy
[33:15.470 --> 33:22.790]  was the DNS over Tor. So, doing DNS over HTTPS over a hidden service in Tor.
[33:23.430 --> 33:29.990]  But one of the problems with that is that people can see they're using Tor. So, as I understand
[33:29.990 --> 33:33.970]  the way the ODNS works, it more or less looks like regular DNS traffic. If you do look at it
[33:33.970 --> 33:40.490]  closely enough, you can see the ODNS TLD, which will somewhat flag that. But you have to look
[33:41.150 --> 33:51.350]  fairly hard. But other than that, I don't know of any other issues. But something to think about,
[33:51.350 --> 34:01.250]  certainly. Fantastic. 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:10.990]  Are there any... you know, we're all virtual. I've heard there are, like, hundreds of talks.
[34:10.990 --> 34:15.050]  Are there any other talks that you're really looking forward to seeing during this DEF CON
[34:15.050 --> 34:21.190]  virtual weekend? That's a good question. So, there's actually one that I found out about
[34:21.710 --> 34:30.590]  yesterday. But it was actually earlier. So, and this is... I saw that Chris Weisoppel was
[34:30.590 --> 34:34.490]  doing a talk in the Red Team Village. 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:42.870]  So, and I've got to know him a little bit. 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 --> 35:01.470]  Because I hear the stories about those days from Chris and Christian. But there was more
[35:01.470 --> 35:09.470]  interesting things. Like the... he was talking about pen testing his prospective employer,
[35:09.470 --> 35:14.210]  which was pretty interesting. Because he was, like... not many times do you get the opportunity
[35:14.210 --> 35:20.250]  to hack your future employer's voicemail and find out what they're actually thinking about
[35:20.250 --> 35:25.770]  your negotiations. Because apparently, they were asking for a sneakers van. Like,
[35:25.770 --> 35:30.610]  from the movie Sneakers. And they were, like, these guys want a Winnebago.
[35:32.090 --> 35:36.850]  I don't think they quite understood what the purpose of it was. So, that was actually one
[35:36.850 --> 35:45.790]  that I found about and did get to check out. I've been kind of... blank on the word. But I
[35:45.790 --> 35:49.690]  haven't really been keeping up with all the entire schedule. 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:10.610]  Yeah, I'm looking forward to all of them, too. And thankfully, everything is going to be
[36:10.610 --> 36:17.130]  available after the conference to download, to stream on various services. Oh! We have another
[36:17.130 --> 36:24.390]  question that just came in. 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:32.630]  Yes. I'm not sure if you caught the... so, somebody else asked about an implementation. And
[36:33.730 --> 36:38.070]  so, as far as I know, there's a Golang implementation out there that the researchers
[36:38.070 --> 36:44.170]  used. And I believe it's on GitHub, but I don't remember. I could be remembering incorrectly.
[36:44.570 --> 36:50.410]  But it is referenced in their paper. So, if you caught that from my reference slide,
[36:50.410 --> 36:56.370]  or if you just Google for ODNS, you should be able to find their paper fairly easily.
[36:57.030 --> 37:01.590]  And I'll have links there, I think. Pretty sure.
[37:02.130 --> 37:10.210]  Fantastic. Well, thank you so much, again, for your time. And as always, for being a volunteer
[37:10.210 --> 37:15.730]  at the Fitzgerald Privacy Village. I look forward to seeing you, hopefully, in person next year.
[37:15.730 --> 37:16.750]  Yep. Hopefully.
[37:17.030 --> 37:18.970]  And all that other fun stuff. So, thanks again.