start	end	text
2000	8970	Hi, I'm Matt Chung, and I want to talk today about DNS privacy. Now, usually with DNS,
8970	16410	we hear about DNSSEC as in authenticating DNS queries. Here, I'm interested in a different
16410	24330	aspect of DNS security, and that is the privacy of DNS queries to protect users from
26010	31290	eavesdroppers finding out what sort of sites they're visiting if they are of sensitive nature.
32050	39090	And I decided to talk about this topic after coming across a paper that I found about a year
39090	46530	ago that talked about a novel approach to this problem. And so I decided to create this talk
46530	53690	that goes over some of my experience with this topic over the years, leading up to this paper
53690	61560	and some future thoughts about the topic. To begin with, I'm just going to do a brief
61560	67120	introduction to DNS, just a very high-level introduction so that we know what we're
67120	74660	talking about, and then we can talk about how we can preserve DNS privacy.
76500	84840	So, at a very high level, DNS, or the domain name system, is a way of translating a host name
84840	91780	into an IP address so we can find that on the internet. And basically, the way that works is
91780	101280	when your client is trying to access a site on a host, then it first sends out that host name
101960	109000	to its DNS server, which, if it doesn't know it, will try the root name server. And in this case,
109000	115700	if they're looking for www.wikipedia.org, it tries the root name server, and it says,
115700	122080	well, I don't know where that is, but try the org name server. And the org name server may say,
122080	128240	I don't know where that is, but try the wikipedia.org name server. And from there,
128240	134920	that name server says, oh, I know, it's this IP address. So it has this hierarchical structure
134920	144890	that it works through recursively. Now, the first aspect of DNS privacy that I'm going to talk about
144890	152390	is what we sort of call local privacy. It's the first aspect that I considered in terms of my own
152390	160050	personal threat model. And so we'll discuss what the challenge is and some solutions that can
160050	174630	easily be undertaken. So the first situation is you might be browsing the web at a cafe using open
174630	184110	Wi-Fi. And so what I have here is just a screenshot of Wireshark capturing DNS packets.
184490	189950	Now, this isn't particularly for Wi-Fi, but this just gives an example of what that would look like.
189950	198990	Here, we're seeing a DNS query for google.com. And it would be very simple for somebody with
199630	206970	a laptop and Wi-Fi card to sniff traffic like this on open Wi-Fi at a coffee shop. So
209170	215430	as you can see, it's all plain text. In this case, looking at google.com,
215430	221570	it's generally not considered a purely sensitive post. But if you're looking up information about
221790	229190	a health condition or any other issue that you don't want to... or other information that you
229190	235250	don't want people to know that you're looking up for the reason if it's not considered socially
235250	242730	acceptable, you don't want people to just be able to sniff that information over Wi-Fi.
242730	251690	So the first solution that I considered over the years was to tunnel DNS over SOCKS proxies. So
252870	258550	first, I just wanted to make sure that all traffic was being encrypted, especially
259550	269510	10 plus years ago, not every site was using HTTPS. So if I was out and using open Wi-Fi,
269510	275630	I would use an SSH server that I was running and tunnel all of my traffic through there.
275870	284250	And this diagram just gives a basic overview of what that does. But the idea is I use SSH,
284250	292810	which is an encrypted protocol, as a tunnel for all the rest of my web traffic. And by default,
292810	302130	most browsers will tunnel the main HTTP traffic, but it doesn't always tunnel the DNS traffic.
302130	310530	So ultimately, the SOCKS proxy will tunnel it to the remote server over SSH. And then from there,
310530	318050	it all gets sent as if you were local there. So whether it was any traffic that is encrypted or
318050	326710	plain text gets sent from that location. So the idea being that I don't trust my immediate Wi-Fi
326710	336750	neighborhood, but I might have greater trust in the network area where the SSH server resides.
339010	347070	As I mentioned, browsers don't necessarily, by default, tunnel DNS traffic over SOCKS proxies.
347070	354570	However, in browsers like Firefox, there's usually a setting that you can set. So in this case,
354570	361010	if you go to about config, you'll get a little warning that making changes to these settings
361750	369990	may be dangerous. But if you search for SOCKS remote DNS, you'll see that by default,
369990	375010	this actual value is set to false, but you can set it to true. And then whenever you're using
375150	381110	a SOCKS proxy, it gets sent over that. And if you're using SSH, it's all encrypted. So
381690	387110	the only traffic that somebody over Wi-Fi will see is SSH traffic. And they won't even be able
387110	395510	to tell if you're surfing the web or making any other DNS queries. It's all tunneled over SSH.
398830	406550	The other alternative is to use a VPN. Many people use VPNs now. Corporations use VPNs for
406550	413070	remote workers, which is especially common nowadays. And that just tunnels all traffic
413670	421710	from one machine over to another over an encrypted tunnel. Similar to the SSH setup,
421710	428390	however, with the SSH SOCKS proxy, that was primarily web traffic. Other network connections
429080	438990	could be sent over the local network. And in that case, those DNS queries could be leaked out.
440910	448890	But it requires a little bit more infrastructure to set up a VPN. Many Linux servers, Linux machines
448890	454870	have SSH just installed by default. So it's simpler if you have a home machine, you could
454870	467630	do the SSH SOCKS proxying without having to set up a VPN. And then the next consideration I had,
467630	473150	and this is something that I played around with, but many of you are maybe familiar with Tor.
473650	481930	And this just gives a brief overview of how Tor works. Tor basically encrypts your communication
482750	490650	through multiple hops, so that your client and the first entry node into the Tor network
490650	497070	know about each other. And that node knows about the next node. And then that next node
497070	503530	knows about the exit node. But each node doesn't know about ones outside of the ones that they're
503530	513410	communicating with. And each level is encrypted. Now, Tor only works with TCP traffic, and DNS is
513930	520770	a UDP protocol. And we're not going to worry too much about the details of that. But typically,
520770	530950	Tor clients will actually, underlying, it's using a SOCKS proxy, and it will just manually,
530950	537070	forward that host name all the way to the exit relay. And then the exit relay will make the
537070	547070	DNS request, and then forward that back to the client for the final TCP connection.
548790	555490	So this provides perhaps even more protection than the others, because
557670	567470	it disassociates the client with the DNS in a more obfuscated way. However, there are
568240	575430	network analysis attacks that could correlate the query, the traffic from the client,
575430	587130	including the DNS queries, back to the exit node. So now we'll talk about encrypted DNS protocols.
587130	594410	So in this case, we're going to have modified DNS protocols that will encrypt the traffic
594410	602690	to prevent eavesdropping and protect the confidentiality of their queries.
605170	614510	The first one is DNS over HTTPS slash TLS. Now, many of you may know that HTTPS is just HTTP
614510	622460	over TLS, so you might wonder what's the difference. Primarily, the main difference is that
623470	632190	DNS over HTTPS uses port 443 and will look like regular HTTPS traffic to anyone who's observing
632190	642790	it, whereas DNS over TLS uses its own dedicated port of 853. And there are pros and cons to
643590	651330	using this protocol, the different protocols here, depending on your perspective. From a privacy
651330	658790	perspective, DNS over HTTPS is generally the preferred one because you're not only hiding
658790	663470	the DNS query, but you're also hiding the fact that you're making a DNS query by just making
663470	669790	it look like it's a regular HTTPS traffic. For network administrators, though, they might want
669790	677890	to know that DNS queries are being made so that they can potentially be blocked, and so DNS over
677890	691690	TLS is generally preferred in that situation. Now, as I mentioned before, Tor, by default,
693190	700890	has a mechanism to make, essentially, DNS queries on behalf of the client
700890	708090	without you really tunneling the full DNS protocol over the Tor network. But there's also
708780	716090	been work towards actually implementing a DNS protocol over Tor. That's something that
716090	726890	Cloudflare has been doing. So Cloudflare also does the DNS over TLS, but they
726890	736470	are also doing DNS over Tor. And so, briefly, how that's working is, first, using a hidden service.
736470	745270	And just to briefly describe what hidden services are in Tor, basically, there is a rendezvous point
745270	752610	in the middle of the Tor network, and the hidden service and the client
753570	760130	essentially connect through that rendezvous point. So they don't actually know who's on either side
760130	769810	of it. But it's so that all the traffic is living inside the Tor network. And, essentially, DNS over
771530	778970	HTTPS or DNS over TLS can be tunneled through this hidden service. And that's one other
778970	791960	service that Cloudflare provides. Now, this protocol that I read about and referred to earlier
792900	800360	that came out a little over a year ago, it was called Oblivious DNS. And this takes a bit of a
800360	809180	different take on how to protect the privacy of clients. So this diagram goes over the basic
809180	817740	protocol. And I'll just talk through how it works. So the client would have an ODNS stub
817740	827820	running on their machine. And it would talk to a DNS recursive server. And
830750	837660	what it would... what the ODNS stub will do is create a session key and encrypt the DNS
837660	848600	name. And then append the .odns top-level domain to the domain name. So the encrypt...
848600	854400	the domain name gets encrypted, but will then act as like a regular domain name. And then
857880	865240	the authoritative ODNS server will have a public key, which will be used by the ODNS
865240	871300	stub to encrypt the session key. And that gets sent along with additional information in the
871300	880120	additional information section of the DNS request. That gets forwarded onto the recursive DNS server,
880120	889920	which then sends that off to the authoritative ODNS server. So what this does is it hides
889920	898200	the query from the recursive DNS server that you can see right after the stub.
898200	905300	So this server here can't tell what host the client is looking for. And over here,
906060	912800	it can't tell where that request came from. So even though it will decrypt the session key and
912800	918820	then decrypt the original host name that the client was looking for, all it knows is it came
918820	926800	from this recursive server and not from the client. And then from there, it acts as a regular
926800	938900	DNS server. Now in the actual implementation, they have it fall back to regular DNS if the ODNS stub
938900	944200	doesn't work. And in the paper, they get into more details about
945880	955680	how to manage load balancing of the DNS servers. But the basic idea is to hide
956780	964980	the information from this server so that if anybody were able to compromise the recursive
964980	971760	server, they wouldn't be able to tell what hosts the client was looking for. And on this end,
971760	976340	on the authoritative ODNS server, you wouldn't be able to know which clients were making the
976340	985300	requests in the first place. And this differs from the DNS over HTTPS and DNS over TLS standard
985300	991760	setups because even though that preserves privacy from an eavesdropper on the network,
991760	999680	someone could still gain access to the DNS server and it could be logged who made which request.
1001220	1009160	So if this was through a government request or somebody hacked the server and dumped logs,
1009160	1016920	you're still vulnerable. Or even if it wasn't logged, a hacker could then monitor what's going
1016920	1022940	on that DNS server. So it will compromise the privacy of everybody who uses
1023480	1034340	that server, whether it's over TLS or not. And this way, it keeps information separate
1035100	1044760	and makes it harder to correlate. I will say that the DNS over Tor seems to accomplish a similar task,
1044760	1056180	but I think this was a very interesting solution to the problem. And I just will include here
1056180	1065460	for a moment and just reiterate the basic process. So when you are going to make a DNS request,
1065460	1071700	you first generate a session key. And hopefully this makes it a little more clear. You encrypt
1071700	1078540	the domain name. And so that's what the brackets are indicating is that the original domain name,
1078540	1087940	in this case foo.com, is being encrypted with the session key K. And then it's appended with
1087940	1097220	the ODNS top level domain. And then the session key is encrypted with the ODNS authoritative
1097220	1104500	server's public key. And it's included in the additional information section in the DNS request.
1104900	1113500	So that it essentially looks like regular DNS traffic, but it's still encrypted and preserves
1113500	1125000	that privacy. And makes for an easy fallback to regular DNS. So after seeing this, and it was
1125000	1132060	because when I first saw the title of Oblivious DNS, it made me think of a particular cryptographic
1132060	1137680	primitive that I learned about 10 years ago called Oblivious Transfer. And that was actually
1137680	1143160	initially what I thought it was going to involve. And it didn't. But it got me to thinking that
1143160	1152760	perhaps one could combine these two just to add an additional layer of potential privacy.
1152760	1159740	So the concern I have is that actually if we go back and look at
1161560	1171020	the diagram of the Oblivious DNS setup, if one had enough network visibility,
1171020	1178900	they could potentially see traffic going from the ODNS stub to the DNS, recursive DNS server,
1178900	1186140	and then from there to the authoritative server and then help found there. That'd be a lot of
1186140	1192260	network visibility, but it's conceivable. And so there could be correlations between
1192260	1199580	the DNS requests made by the authoritative server and the requests coming from the clients.
1199580	1211020	So it got me thinking, what if the authoritative ODNS server cast results like most DNS servers do,
1211020	1217540	and these would have to be invalidated after a timeout as, again, as regular DNS servers do,
1217540	1224720	but they could store it in what's called an encrypted distributed hash table. And so that
1224720	1235200	I can talk about how one could essentially query the authoritative server. And this is
1235200	1239840	very high level. I don't have a fully worked out protocol, but just something to think about.
1239840	1247660	But they could query the authoritative server to see if it already knows the host that it's
1247660	1257220	for without revealing what that host is. And then if it already knows it, it can get that
1257220	1265260	IP address, again, without revealing additional IP addresses from the DNS server and revealing
1265260	1272080	which host to the DNS server the client is looking for. So that involves a couple of things first.
1272080	1281800	So with a hash table, you have a key that you need to search for. And so you need some way of
1281800	1290260	searching text. And you can use additively homomorphic encryption to do this. And I'll
1290260	1296220	describe actually in a plain text version of the protocol first how that works. And then
1298060	1304900	you can see how if I'll briefly explain additively homomorphic encryption, and you
1304900	1313240	can see how this technique would allow you to send an encrypted query to search the hash table
1313240	1317960	to see if the key exists. And then we'll talk about blues transfer and how to actually get the
1317960	1327800	value out of it. So this protocol was developed actually for, well, as a modification
1328680	1338380	of a neural network protocol or method to do text pattern matching. And it was developed
1339300	1346720	as a way of creating an encrypted text pattern match protocol. And the way it works is that you
1346720	1353600	have some alphabet. In the original technique, it was... in the original protocol, they were
1353600	1360300	concerned with potentially searching for DNA sequence patterns. So you'll see the alpha
1360300	1371620	that here is A, C, G, and T. And what you do is you have what you call a character delay vector.
1371620	1381040	So for each letter in the alphabet, you say, okay, the idea is assuming as we're moving through
1381040	1390020	the text that we're searching, if at this point from here on out, we're going to match the pattern,
1390020	1398460	how much further should we go in order to say that we're at the end of the... what we mean so that
1398460	1402400	it's at the end of the pattern. A little complicated, but we'll look at this example
1402400	1412420	here. So the pattern here is TACT, T-A-C-T. And the first letter is A. So if that... if the A that
1412420	1422180	we find is in this... is part of this pattern, then two letters later, we'll be at the end of
1422940	1430160	the pattern. So we'll put a one there. If... or for the next letter, C, if we find a C,
1430160	1436200	then there's only one letter later that we need to go to get to the end of the pattern.
1436920	1444760	There are no Gs, so if we find a G, we're not in that pattern at all. And for T,
1444760	1449400	there's actually two possibilities. We could be at the beginning of the pattern,
1449400	1455480	in which case you'd put a one at the end of this little vector.
1457100	1463460	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.
1463480	1469360	And if it's the T from the beginning... sorry, T from the end, then we put a one at the beginning
1469360	1476280	of the vector. So you'll see this one, zero, zero, one vector. The ones correspond to the
1476280	1483300	opposite Ts from the original pattern. And this diagram basically shows how
1484290	1490780	this text pattern matching algorithm works. You start off with a vector of all zeros, and then
1492430	1498700	through each letter in the text you're searching, you go through... you get the
1498700	1504640	corresponding vector from the pattern you're searching, and you just add shifting one over
1504640	1512720	as you go. So with G being the first letter, those all zeros, we add that, the vector remains unchanged.
1512960	1522900	We take the next letter A, and we add this vector one, zero, zero, one, zero, and we get... we update the
1522900	1530240	activation vector, as it's called, and so on and so forth. And you'll see that at the end,
1530240	1537120	because the pattern is there, there is a four, because that's the length of the pattern.
1537760	1547080	And the idea is that when you have the entire pattern, those ones all will add up in the same spot
1547920	1551500	to the whole length of the pattern you're looking for.
1554140	1562120	And so, basically, you just look for the number four, and you might say, okay, the pattern was found.
1562860	1570660	Now, as I mentioned, we want to do this in encrypted fashion. It turns out there are some
1570660	1578360	cryptographic algorithms that allow you to perform an operation that will give you the
1579360	1587580	ciphertext of the sum of the plaintext. So, if you have an encryption of zero and an encryption of one,
1587580	1592800	you can do an operation, and you'll get, well, in that case, the encryption of one as well. Or,
1592800	1597200	if you have an encryption of one and another encryption of one, and you perform an operation,
1597200	1602820	you'll get something that will be equivalent to the encryption of two. In other words,
1602820	1607540	if you decrypt that value, run it through the decryption algorithm, you'll get out two.
1608180	1615780	So on and so forth. So, the idea here is that you would encrypt these values, so you'd have
1615780	1623340	an encryption of zero, an encryption of zero, an encryption of one, an encryption of zero for A,
1623340	1631860	similarly for C, G, and T. And then you can do the same addition, as we see here,
1632400	1639660	and you'll end up with a vector that will have a value that's an encryption of four.
1639660	1647900	Now, one nice trick is that you can essentially subtract the encryption of the pattern length
1647900	1654060	from the entire vector. And then, instead of looking for the length of the pattern,
1654060	1659500	you're going to look for zero. And this is useful because there are some algorithms,
1659500	1667200	some ciphers, that while they do perform this homomorphic operation, it's actually
1667200	1676260	hard to really decrypt them. One example is using elliptic curves,
1676780	1683460	where the encryption of a number M is M times a base point. I won't get into too many details
1683460	1687760	about that. But for those who are familiar with elliptic curves, you can see that that's
1687760	1695340	additively homomorphic, but based on the security of the cipher, actually finding out what that M
1695340	1701000	is from a given point is hard. But if you're actually looking for zero, you know that's
1701000	1709540	going to be the identity, and that's easy to identify. So that's basically how you can do this
1709540	1714620	search in the key space of the hash table.
1716120	1724820	And then, once you know if the host name is in the cache of the Oblivious DNS server,
1724820	1731070	then you want to actually retrieve it. And here we'll use a technique called Oblivious Transfer.
1731630	1739170	And basically what this is, is we have an index into the... so maybe we find out that it was the
1739170	1748850	fifth host that was in the list. Then we can essentially request the fifth entry without
1748850	1756670	revealing that we're actually asking for that one. And the DNS server will send us back data that
1757470	1763610	will only give us information about the fifth one and not any of the other IPs for the other hosts.
1764650	1771170	Now, I will admit that Oblivious Transfer actually has a fairly high bandwidth, so
1771790	1779030	requires a lot of data transfer. But that's something that could be considered for the future.
1781450	1791010	And just want to end with some references for the actual... above is the actual paper that
1791010	1799110	started this idea for this talk, the Oblivious DNS paper. And then a couple links to Cloudflare
1799110	1809970	that just talks about the DNS over HTTPS and DNS over TOR. So with that, I look forward to
1809970	1848650	answering any questions. Thank you. Hi Matt, what a fantastic talk. Thank you so much for speaking
1849250	1854210	this year again at the Crypto Privacy Village as a longtime volunteer. It's always great to
1854210	1862610	have you back. I am pulling up some questions here from the Discord. Oh yeah, I see that one
1862610	1869070	coming through. So there's a question. Do you mind if I... Oh yeah, go ahead. Go ahead, please take it.
1869070	1873270	Yeah, so I see that somebody's asking, are there any implementations of ODNS?
1873490	1880390	If I recall correctly from the paper which I referenced in the reference slide, they do refer
1880390	1886550	to a Go implementation, I believe. So they do have one. I actually mean to check it out,
1886550	1892990	but I haven't got around to it. But yeah, if you grab the link off the slide deck or
1892990	1897910	if you just search for ODNS or Oblivious DNS, it shouldn't be hard to find.
1899070	1904210	And the one thing that occurred to me when thinking about playing with this is, well,
1904210	1910890	if I don't have more than one person using the same server, then it semi-defeats the purpose.
1910890	1916710	Because part of the point is to have multiple people connecting to the same ODNS server and
1917770	1926310	making it difficult to track which one made which request. But yeah, that's something I've
1926310	1935070	been thinking about playing around with myself. Fantastic. Does anyone have any more questions
1935070	1945600	for Matt? You can drop them into the Discord. People are typing.
1950950	1954770	Yeah, I figured it wasn't like a super technical talk, so there might not be a ton of questions,
1954770	1960210	but just something that I came across last year. I was like, this sounds interesting. I want to
1960210	1965690	read up on it and figured this would be a good way to force myself to actually read the paper.
1966430	1972830	We have another question that just came in. Are there specific foreseeable problems with ODNS?
1973510	1980010	Oh, that's a good question. So, not necessarily that I can think of. So,
1980010	1985190	one of the things I've been thinking about is comparing ODNS versus some of the other options.
1986670	1995470	One of the... like, I think the only other option that provides similar levels of privacy
1995470	2002790	was the DNS over Tor. So, doing DNS over HTTPS over a hidden service in Tor.
2003430	2009990	But one of the problems with that is that people can see they're using Tor. So, as I understand
2009990	2013970	the way the ODNS works, it more or less looks like regular DNS traffic. If you do look at it
2013970	2020490	closely enough, you can see the ODNS TLD, which will somewhat flag that. But you have to look
2021150	2031350	fairly hard. But other than that, I don't know of any other issues. But something to think about,
2031350	2041250	certainly. Fantastic. I will... I'll throw a question at you, since I have you.
2041250	2045890	And just to give anyone some extra time, if they have any additional questions.
2046730	2050990	Are there any... you know, we're all virtual. I've heard there are, like, hundreds of talks.
2050990	2055050	Are there any other talks that you're really looking forward to seeing during this DEF CON
2055050	2061190	virtual weekend? That's a good question. So, there's actually one that I found out about
2061710	2070590	yesterday. But it was actually earlier. So, and this is... I saw that Chris Weisoppel was
2070590	2074490	doing a talk in the Red Team Village. So, I actually did check that out this morning.
2075390	2078370	You know, partially because he's the founder of the company I work for.
2078410	2082870	So, and I've got to know him a little bit. I was curious to see what he had to say.
2083350	2088730	And we got to learn a little bit more about his history with Loft, which was pretty cool.
2089390	2101470	Because I hear the stories about those days from Chris and Christian. But there was more
2101470	2109470	interesting things. Like the... he was talking about pen testing his prospective employer,
2109470	2114210	which was pretty interesting. Because he was, like... not many times do you get the opportunity
2114210	2120250	to hack your future employer's voicemail and find out what they're actually thinking about
2120250	2125770	your negotiations. Because apparently, they were asking for a sneakers van. Like,
2125770	2130610	from the movie Sneakers. And they were, like, these guys want a Winnebago.
2132090	2136850	I don't think they quite understood what the purpose of it was. So, that was actually one
2136850	2145790	that I found about and did get to check out. I've been kind of... blank on the word. But I
2145790	2149690	haven't really been keeping up with all the entire schedule. So, I need to take a look at that.
2150350	2157150	But of course, I also enjoyed the talks from the village... from this village so far today.
2157150	2162430	Been watching the streams since 10 Pacific time.
2162950	2163810	Fantastic.
2163810	2165670	And look forward to the ones tomorrow, too.
2165670	2170610	Yeah, I'm looking forward to all of them, too. And thankfully, everything is going to be
2170610	2177130	available after the conference to download, to stream on various services. Oh! We have another
2177130	2184390	question that just came in. Are there any practical implementations of ODNS yet?
2184390	2186890	Or is this theoretical at this point?
2187510	2192630	Yes. I'm not sure if you caught the... so, somebody else asked about an implementation. And
2193730	2198070	so, as far as I know, there's a Golang implementation out there that the researchers
2198070	2204170	used. And I believe it's on GitHub, but I don't remember. I could be remembering incorrectly.
2204570	2210410	But it is referenced in their paper. So, if you caught that from my reference slide,
2210410	2216370	or if you just Google for ODNS, you should be able to find their paper fairly easily.
2217030	2221590	And I'll have links there, I think. Pretty sure.
2222130	2230210	Fantastic. Well, thank you so much, again, for your time. And as always, for being a volunteer
2230210	2235730	at the Fitzgerald Privacy Village. I look forward to seeing you, hopefully, in person next year.
2235730	2236750	Yep. Hopefully.
2237030	2238970	And all that other fun stuff. So, thanks again.