1
00:00:02,000 --> 00:00:07,250
Hi, I'm Matt Chung, and I want to talk today about DNS privacy.

2
00:00:07,310 --> 00:00:13,870
Now, usually with DNS, we hear about DNSSEC as in authenticating DNS queries.

3
00:00:13,870 --> 00: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.

4
00:00:32,050 --> 00: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.

5
00:00:43,470 --> 00: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.

6
00:00:59,080 --> 00: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.

7
00:01:16,500 --> 00: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.

8
00:01:29,320 --> 00: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.

9
00:01:47,760 --> 00: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.

10
00:02:00,180 --> 00:02:06,200
And the org name server may say, I don't know where that is, but try the wikipedia.org name server.

11
00:02:06,660 --> 00:02:12,520
And from there, that name server says, oh, I know, it's this IP address.

12
00:02:12,520 --> 00:02:17,160
So it has this hierarchical structure that it works through recursively.

13
00:02:21,030 --> 00: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.

14
00:02:27,910 --> 00:02:33,910
It's the first aspect that I considered in terms of my own personal threat model.

15
00:02:34,370 --> 00:02:42,470
And so we'll discuss what the challenge is and some solutions that can easily be undertaken.

16
00:02:45,430 --> 00:02:55,770
So the first situation is you might be browsing the web at a cafe using open Wi-Fi.

17
00:02:56,230 --> 00:03:04,110
And so what I have here is just a screenshot of Wireshark capturing DNS packets.

18
00:03:04,490 --> 00:03:09,950
Now, this isn't particularly for Wi-Fi, but this just gives an example of what that would look like.

19
00:03:09,950 --> 00:03:15,490
Here, we're seeing a DNS query for google.com.

20
00:03:15,750 --> 00: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.

21
00:03:26,730 --> 00:03:31,830
So as you can see, it's all plain text.

22
00:03:31,950 --> 00:03:39,150
In this case, looking at google.com, it's generally not considered a purely sensitive post.

23
00:03:39,150 --> 00: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.

24
00:04:02,730 --> 00:04:11,550
So the first solution that I considered over the years was to tunnel DNS over SOCKS proxies.

25
00:04:11,550 --> 00: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.

26
00:04:24,630 --> 00: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.

27
00:04:35,870 --> 00:04:41,230
And this diagram just gives a basic overview of what that does.

28
00:04:41,230 --> 00: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.

29
00:04:50,930 --> 00:05:02,130
And by default, most browsers will tunnel the main HTTP traffic, but it doesn't always tunnel the DNS traffic.

30
00:05:02,130 --> 00:05:09,570
So ultimately, the SOCKS proxy will tunnel it to the remote server over SSH.

31
00:05:09,570 --> 00:05:15,050
And then from there, it all gets sent as if you were local there.

32
00:05:15,050 --> 00:05:20,890
So whether it was any traffic that is encrypted or plain text gets sent from that location.

33
00:05:20,890 --> 00: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.

34
00:05:39,010 --> 00:05:47,070
As I mentioned, browsers don't necessarily, by default, tunnel DNS traffic over SOCKS proxies.

35
00:05:47,070 --> 00:05:53,150
However, in browsers like Firefox, there's usually a setting that you can set.

36
00:05:53,150 --> 00: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.

37
00:06:03,030 --> 00: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.

38
00:06:13,790 --> 00:06:18,150
And then whenever you're using a SOCKS proxy, it gets sent over that.

39
00:06:18,150 --> 00:06:20,950
And if you're using SSH, it's all encrypted.

40
00:06:20,950 --> 00:06:26,550
So the only traffic that somebody over Wi-Fi will see is SSH traffic.

41
00:06:26,550 --> 00:06:32,570
And they won't even be able to tell if you're surfing the web or making any other DNS queries.

42
00:06:32,570 --> 00:06:35,510
It's all tunneled over SSH.

43
00:06:38,830 --> 00:06:42,070
The other alternative is to use a VPN.

44
00:06:42,290 --> 00:06:44,170
Many people use VPNs now.

45
00:06:44,970 --> 00:06:50,330
Corporations use VPNs for remote workers, which is especially common nowadays.

46
00:06:50,330 --> 00:06:59,570
And that just tunnels all traffic from one machine over to another over an encrypted tunnel.

47
00:06:59,570 --> 00:07:06,990
Similar to the SSH setup, however, with the SSH SOCKS proxy, that was primarily web traffic.

48
00:07:06,990 --> 00:07:13,270
Other network connections could be sent over the local network.

49
00:07:13,310 --> 00:07:18,990
And in that case, those DNS queries could be leaked out.

50
00:07:20,910 --> 00:07:25,550
But it requires a little bit more infrastructure to set up a VPN.

51
00:07:26,710 --> 00:07:31,830
Many Linux servers, Linux machines have SSH just installed by default.

52
00:07:31,830 --> 00: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.

53
00:07:44,110 --> 00: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.

54
00:07:53,650 --> 00:07:57,270
And this just gives a brief overview of how Tor works.

55
00:07:57,770 --> 00: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.

56
00:08:12,230 --> 00:08:14,730
And that node knows about the next node.

57
00:08:15,030 --> 00:08:18,730
And then that next node knows about the exit node.

58
00:08:18,730 --> 00:08:24,950
But each node doesn't know about ones outside of the ones that they're communicating with.

59
00:08:24,950 --> 00:08:27,690
And each level is encrypted.

60
00:08:28,090 --> 00:08:36,090
Now, Tor only works with TCP traffic, and DNS is a UDP protocol.

61
00:08:36,770 --> 00:08:39,710
And we're not going to worry too much about the details of that.

62
00:08:39,710 --> 00: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.

63
00:08:55,010 --> 00: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.

64
00:09:08,790 --> 00: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.

65
00:09:26,430 --> 00: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.

66
00:09:43,890 --> 00:09:47,130
So now we'll talk about encrypted DNS protocols.

67
00:09:47,130 --> 00: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.

68
00:10:05,170 --> 00:10:09,990
The first one is DNS over HTTPS slash TLS.

69
00:10:09,990 --> 00:10:18,410
Now, many of you may know that HTTPS is just HTTP over TLS, so you might wonder what's the difference.

70
00:10:18,610 --> 00: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.

71
00:10:39,790 --> 00:10:50,630
And there are pros and cons to using this protocol, the different protocols here, depending on your perspective.

72
00:10:50,630 --> 00: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.

73
00:11:07,390 --> 00: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.

74
00:11:26,490 --> 00: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.

75
00:11:46,750 --> 00:11:55,150
But there's also been work towards actually implementing a DNS protocol over Tor.

76
00:11:55,150 --> 00:11:58,470
That's something that Cloudflare has been doing.

77
00:11:58,470 --> 00:12:10,890
So Cloudflare also does the DNS over TLS, but they are also doing DNS over Tor.

78
00:12:10,890 --> 00:12:16,470
And so, briefly, how that's working is, first, using a hidden service.

79
00:12:16,470 --> 00: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.

80
00:12:36,750 --> 00:12:41,190
So they don't actually know who's on either side of it.

81
00:12:41,190 --> 00:12:45,810
But it's so that all the traffic is living inside the Tor network.

82
00:12:46,150 --> 00:12:57,690
And, essentially, DNS over HTTPS or DNS over TLS can be tunneled through this hidden service.

83
00:12:57,690 --> 00:13:02,490
And that's one other service that Cloudflare provides.

84
00:13:06,880 --> 00: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.

85
00:13:17,540 --> 00:13:25,260
And this takes a bit of a different take on how to protect the privacy of clients.

86
00:13:25,260 --> 00:13:30,060
So this diagram goes over the basic protocol.

87
00:13:30,060 --> 00:13:32,880
And I'll just talk through how it works.

88
00:13:32,880 --> 00:13:39,640
So the client would have an ODNS stub running on their machine.

89
00:13:39,720 --> 00:13:46,860
And it would talk to a DNS recursive server.

90
00:13:47,800 --> 00:13:58,880
And what it would... what the ODNS stub will do is create a session key and encrypt the DNS name.

91
00:13:59,500 --> 00:14:06,920
And then append the .odns top-level domain to the domain name.

92
00:14:06,920 --> 00:14:08,600
So the encrypt...

93
00:14:08,600 --> 00:14:13,180
the domain name gets encrypted, but will then act as like a regular domain name.

94
00:14:13,440 --> 00:14:14,400
And then

95
00:14:17,880 --> 00: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.

96
00:14:28,840 --> 00:14:35,160
And that gets sent along with additional information in the additional information section of the DNS request.

97
00:14:35,160 --> 00:14:46,860
That gets forwarded onto the recursive DNS server, which then sends that off to the authoritative ODNS server.

98
00:14:46,860 --> 00: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.

99
00:14:58,200 --> 00:15:03,800
So this server here can't tell what host the client is looking for.

100
00:15:03,880 --> 00:15:09,700
And over here, it can't tell where that request came from.

101
00:15:09,700 --> 00: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.

102
00:15:24,740 --> 00:15:28,140
And then from there, it acts as a regular DNS server.

103
00:15:30,180 --> 00:15:40,480
Now in the actual implementation, they have it fall back to regular DNS if the ODNS stub doesn't work.

104
00:15:41,120 --> 00:15:50,360
And in the paper, they get into more details about how to manage load balancing of the DNS servers.

105
00:15:50,360 --> 00: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.

106
00:16:10,500 --> 00: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.

107
00:16:17,740 --> 00: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.

108
00:16:41,220 --> 00:16:50,680
So if this was through a government request or somebody hacked the server and dumped logs, you're still vulnerable.

109
00:16:50,680 --> 00:16:59,580
Or even if it wasn't logged, a hacker could then monitor what's going on that DNS server.

110
00:16:59,640 --> 00:17:07,140
So it will compromise the privacy of everybody who uses that server, whether it's over TLS or not.

111
00:17:07,480 --> 00:17:17,120
And this way, it keeps information separate and makes it harder to correlate.

112
00:17:17,420 --> 00: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.

113
00:17:33,880 --> 00:17:40,700
And I just will include here for a moment and just reiterate the basic process.

114
00:17:40,700 --> 00:17:47,660
So when you are going to make a DNS request, you first generate a session key.

115
00:17:47,980 --> 00:17:50,740
And hopefully this makes it a little more clear.

116
00:17:50,740 --> 00:17:53,840
You encrypt the domain name.

117
00:17:53,840 --> 00: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.

118
00:18:05,020 --> 00:18:11,440
And then it's appended with the ODNS top level domain.

119
00:18:11,480 --> 00:18:19,860
And then the session key is encrypted with the ODNS authoritative server's public key.

120
00:18:19,920 --> 00:18:24,500
And it's included in the additional information section in the DNS request.

121
00:18:24,900 --> 00:18:34,940
So that it essentially looks like regular DNS traffic, but it's still encrypted and preserves that privacy.

122
00:18:35,980 --> 00:18:39,140
And makes for an easy fallback to regular DNS.

123
00:18:42,200 --> 00: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.

124
00:18:57,180 --> 00:19:00,040
And that was actually initially what I thought it was going to involve.

125
00:19:00,200 --> 00:19:01,300
And it didn't.

126
00:19:01,300 --> 00: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.

127
00:19:12,760 --> 00: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.

128
00:19:45,460 --> 00:19:49,660
That'd be a lot of network visibility, but it's conceivable.

129
00:19:49,760 --> 00: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.

130
00:19:59,580 --> 00: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.

131
00:20:23,260 --> 00:20:34,760
And so that I can talk about how one could essentially query the authoritative server.

132
00:20:34,760 --> 00:20:36,460
And this is very high level.

133
00:20:36,460 --> 00:20:39,840
I don't have a fully worked out protocol, but just something to think about.

134
00:20:39,840 --> 00: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.

135
00:20:51,420 --> 00: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.

136
00:21:08,820 --> 00:21:12,080
So that involves a couple of things first.

137
00:21:12,080 --> 00:21:18,400
So with a hash table, you have a key that you need to search for.

138
00:21:19,140 --> 00:21:23,220
And so you need some way of searching text.

139
00:21:24,140 --> 00:21:29,560
And you can use additively homomorphic encryption to do this.

140
00:21:29,960 --> 00:21:35,780
And I'll describe actually in a plain text version of the protocol first how that works.

141
00:21:35,780 --> 00: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.

142
00:21:55,500 --> 00:21:59,820
And then we'll talk about blues transfer and how to actually get the value out of it.

143
00:21:59,820 --> 00: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.

144
00:22:16,680 --> 00:22:24,960
And it was developed as a way of creating an encrypted text pattern match protocol.

145
00:22:24,960 --> 00:22:28,060
And the way it works is that you have some alphabet.

146
00:22:28,060 --> 00:22:38,200
In the original technique, it was... in the original protocol, they were concerned with potentially searching for DNA sequence patterns.

147
00:22:38,200 --> 00:22:42,720
So you'll see the alpha that here is A, C, G, and T.

148
00:22:43,520 --> 00:22:51,620
And what you do is you have what you call a character delay vector.

149
00:22:51,620 --> 00: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.

150
00:23:20,320 --> 00:23:22,680
A little complicated, but we'll look at this example here.

151
00:23:22,680 --> 00:23:27,340
So the pattern here is TACT, T-A-C-T.

152
00:23:27,420 --> 00:23:30,320
And the first letter is A.

153
00:23:30,380 --> 00: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.

154
00:23:43,960 --> 00:23:45,460
So we'll put a one there.

155
00:23:47,060 --> 00: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.

156
00:23:56,920 --> 00:24:03,540
There are no Gs, so if we find a G, we're not in that pattern at all.

157
00:24:03,620 --> 00:24:06,280
And for T, there's actually two possibilities.

158
00:24:06,280 --> 00: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.

159
00:24:17,100 --> 00: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.

160
00:24:23,480 --> 00: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.

161
00:24:30,260 --> 00:24:34,320
So you'll see this one, zero, zero, one vector.

162
00:24:34,440 --> 00:24:39,080
The ones correspond to the opposite Ts from the original pattern.

163
00:24:39,080 --> 00:24:47,420
And this diagram basically shows how this text pattern matching algorithm works.

164
00:24:47,420 --> 00: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.

165
00:25:06,680 --> 00:25:12,720
So with G being the first letter, those all zeros, we add that, the vector remains unchanged.

166
00:25:12,960 --> 00: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.

167
00:25:27,200 --> 00: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.

168
00:25:37,760 --> 00: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.

169
00:25:54,140 --> 00:26:02,120
And so, basically, you just look for the number four, and you might say, okay, the pattern was found.

170
00:26:02,860 --> 00:26:07,720
Now, as I mentioned, we want to do this in encrypted fashion.

171
00:26:07,920 --> 00: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.

172
00:26:22,680 --> 00: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.

173
00:26:32,460 --> 00: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.

174
00:26:42,300 --> 00:26:47,540
In other words, if you decrypt that value, run it through the decryption algorithm, you'll get out two.

175
00:26:48,180 --> 00:26:49,620
So on and so forth.

176
00:26:50,540 --> 00: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.

177
00:27:06,960 --> 00: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.

178
00:27:19,660 --> 00:27:29,900
Now, one nice trick is that you can essentially subtract the encryption of the pattern length from the entire vector.

179
00:27:30,120 --> 00:27:35,420
And then, instead of looking for the length of the pattern, you're going to look for zero.

180
00:27:35,420 --> 00: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.

181
00:27:51,020 --> 00:28:02,120
One example is using elliptic curves, where the encryption of a number M is M times a base point.

182
00:28:02,120 --> 00:28:04,560
I won't get into too many details about that.

183
00:28:05,200 --> 00: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.

184
00:28:17,660 --> 00: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.

185
00:28:24,500 --> 00:28:34,620
So that's basically how you can do this search in the key space of the hash table.

186
00:28:36,120 --> 00: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.

187
00:28:47,580 --> 00:28:51,070
And here we'll use a technique called Oblivious Transfer.

188
00:28:51,630 --> 00: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.

189
00:29:02,590 --> 00:29:11,810
Then we can essentially request the fifth entry without revealing that we're actually asking for that one.

190
00:29:11,830 --> 00: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.

191
00:29:24,650 --> 00:29:33,830
Now, I will admit that Oblivious Transfer actually has a fairly high bandwidth, so requires a lot of data transfer.

192
00:29:34,130 --> 00:29:39,030
But that's something that could be considered for the future.

193
00:29:41,450 --> 00: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.

194
00:29:56,090 --> 00:30:04,510
And then a couple links to Cloudflare that just talks about the DNS over HTTPS and DNS over TOR.

195
00:30:06,570 --> 00:30:11,410
So with that, I look forward to answering any questions.

196
00:30:11,590 --> 00:30:12,690
Thank you.

197
00:30:43,670 --> 00:30:47,210
Hi Matt, what a fantastic talk.

198
00:30:47,210 --> 00:30:53,290
Thank you so much for speaking this year again at the Crypto Privacy Village as a longtime volunteer.

199
00:30:53,370 --> 00:30:55,350
It's always great to have you back.

200
00:30:56,170 --> 00:31:01,470
I am pulling up some questions here from the Discord.

201
00:31:01,670 --> 00:31:03,730
Oh yeah, I see that one coming through.

202
00:31:03,730 --> 00:31:04,990
So there's a question.

203
00:31:04,990 --> 00:31:07,470
Do you mind if I... Oh yeah, go ahead.

204
00:31:07,470 --> 00:31:09,070
Go ahead, please take it.

205
00:31:09,070 --> 00:31:13,270
Yeah, so I see that somebody's asking, are there any implementations of ODNS?

206
00:31:13,490 --> 00: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.

207
00:31:23,850 --> 00:31:25,470
So they do have one.

208
00:31:25,470 --> 00:31:27,850
I actually mean to check it out, but I haven't got around to it.

209
00:31:28,230 --> 00: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.

210
00:31:39,070 --> 00: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.

211
00:31:50,890 --> 00: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.

212
00:32:01,750 --> 00:32:08,870
But yeah, that's something I've been thinking about playing around with myself.

213
00:32:10,850 --> 00:32:11,770
Fantastic.

214
00:32:12,690 --> 00:32:15,590
Does anyone have any more questions for Matt?

215
00:32:15,590 --> 00:32:18,510
You can drop them into the Discord.

216
00:32:24,320 --> 00:32:25,600
People are typing.

217
00:32:30,950 --> 00: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.

218
00:32:38,270 --> 00:32:39,590
I was like, this sounds interesting.

219
00:32:39,590 --> 00: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.

220
00:32:46,430 --> 00:32:48,590
We have another question that just came in.

221
00:32:48,590 --> 00:32:52,830
Are there specific foreseeable problems with ODNS?

222
00:32:53,510 --> 00:32:55,210
Oh, that's a good question.

223
00:32:56,130 --> 00:32:59,790
So, not necessarily that I can think of.

224
00:32:59,790 --> 00:33:05,190
So, one of the things I've been thinking about is comparing ODNS versus some of the other options.

225
00:33:06,670 --> 00:33:18,110
One of the... like, I think the only other option that provides similar levels of privacy was the DNS over Tor.

226
00:33:18,350 --> 00:33:22,790
So, doing DNS over HTTPS over a hidden service in Tor.

227
00:33:23,430 --> 00:33:27,730
But one of the problems with that is that people can see they're using Tor.

228
00:33:28,230 --> 00:33:33,090
So, as I understand the way the ODNS works, it more or less looks like regular DNS traffic.

229
00:33:33,090 --> 00:33:39,530
If you do look at it closely enough, you can see the ODNS TLD, which will somewhat flag that.

230
00:33:39,530 --> 00:33:42,310
But you have to look fairly hard.

231
00:33:42,930 --> 00:33:48,850
But other than that, I don't know of any other issues.

232
00:33:49,470 --> 00:33:52,190
But something to think about, certainly.

233
00:33:55,170 --> 00:33:56,230
Fantastic.

234
00:33:57,070 --> 00:34:01,250
I will... I'll throw a question at you, since I have you.

235
00:34:01,250 --> 00:34:05,890
And just to give anyone some extra time, if they have any additional questions.

236
00:34:06,730 --> 00:34:09,150
Are there any... you know, we're all virtual.

237
00:34:09,150 --> 00:34:10,990
I've heard there are, like, hundreds of talks.

238
00:34:10,990 --> 00:34:16,450
Are there any other talks that you're really looking forward to seeing during this DEF CON virtual weekend?

239
00:34:16,470 --> 00:34:17,990
That's a good question.

240
00:34:18,270 --> 00:34:22,430
So, there's actually one that I found out about yesterday.

241
00:34:22,590 --> 00:34:23,870
But it was actually earlier.

242
00:34:24,070 --> 00:34:32,510
So, and this is... I saw that Chris Weisoppel was doing a talk in the Red Team Village.

243
00:34:32,610 --> 00:34:34,490
So, I actually did check that out this morning.

244
00:34:35,390 --> 00:34:38,370
You know, partially because he's the founder of the company I work for.

245
00:34:38,410 --> 00:34:41,010
So , and I've got to know him a little bit.

246
00:34:41,010 --> 00:34:42,870
I was curious to see what he had to say.

247
00:34:43,350 --> 00:34:48,730
And we got to learn a little bit more about his history with Loft, which was pretty cool.

248
00:34:49,390 --> 00:34:59,070
Because I hear the stories about those days from Chris and Christian.

249
00:34:59,890 --> 00:35:02,430
But there was more interesting things.

250
00:35:02,430 --> 00:35:10,370
Like the... he was talking about pen testing his prospective employer, which was pretty interesting.

251
00:35:10,370 --> 00: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.

252
00:35:22,690 --> 00:35:25,150
Because apparently, they were asking for a sneakers van.

253
00:35:25,190 --> 00:35:26,870
Like, from the movie Sneakers.

254
00:35:26,870 --> 00:35:30,610
And they were, like, these guys want a Winnebago.

255
00:35:32,090 --> 00:35:34,950
I don't think they quite understood what the purpose of it was.

256
00:35:35,670 --> 00:35:39,830
So, that was actually one that I found about and did get to check out.

257
00:35:40,150 --> 00:35:45,590
I've been kind of... blank on the word.

258
00:35:45,590 --> 00:35:48,270
But I haven't really been keeping up with all the entire schedule.

259
00:35:48,270 --> 00:35:49,690
So, I need to take a look at that.

260
00:35:50,350 --> 00:35:57,150
But of course, I also enjoyed the talks from the village... from this village so far today.

261
00:35:57,150 --> 00:36:02,430
Been watching the streams since 10 Pacific time.

262
00:36:02,950 --> 00:36:03,810
Fantastic.

263
00:36:03,810 --> 00:36:05,670
And look forward to the ones tomorrow, too.

264
00:36:05,670 --> 00:36:07,950
Yeah, I'm looking forward to all of them, too.

265
00:36:07,950 --> 00:36:16,170
And thankfully, everything is going to be available after the conference to download, to stream on various services.

266
00:36:16,170 --> 00:36:16,410
Oh!

267
00:36:16,410 --> 00:36:19,890
We have another question that just came in.

268
00:36:20,010 --> 00:36:24,390
Are there any practical implementations of ODNS yet?

269
00:36:24,390 --> 00:36:26,890
Or is this theoretical at this point?

270
00:36:27,510 --> 00:36:28,150
Yes.

271
00:36:28,890 --> 00:36:32,550
I'm not sure if you caught the... so, somebody else asked about an implementation.

272
00:36:32,630 --> 00:36:39,230
And so, as far as I know, there's a Golang implementation out there that the researchers used.

273
00:36:39,710 --> 00:36:42,590
And I believe it's on GitHub, but I don't remember.

274
00:36:42,590 --> 00:36:44,170
I could be remembering incorrectly.

275
00:36:44,570 --> 00:36:48,430
But it is referenced in their paper.

276
00:36:48,650 --> 00: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.

277
00:36:57,030 --> 00:36:59,630
And I'll have links there, I think.

278
00:37:00,770 --> 00:37:01,590
Pretty sure.

279
00:37:02,130 --> 00:37:03,010
Fantastic.

280
00:37:03,810 --> 00:37:07,450
Well, thank you so much, again, for your time.

281
00:37:07,830 --> 00:37:12,210
And as always, for being a volunteer at the Fitzgerald Privacy Village.

282
00:37:12,210 --> 00:37:15,730
I look forward to seeing you, hopefully, in person next year.

283
00:37:15,730 --> 00:37:16,010
Yep.

284
00:37:16,010 --> 00:37:16,750
Hopefully.

285
00:37:17,030 --> 00:37:18,330
And all that other fun stuff.

286
00:37:18,330 --> 00:37:18,970
So, thanks again.