Hi, I am very grateful to everyone who spent the time to read the paper and provide feedback. All the comments that I received (both to personal email and here on the mailing list) are excellent and thoughtful.
I would like to use this opportunity to thank Stephen Farrel for kindly suggesting to share the writeup with this mailing list, and to Stephane Bortzmeyer, who pointed out to me the importance of privacy for DNS last year, when I was on a DNS security panel at CCC. Stephane's internet draft, discussing the privacy concerns for DNS, provided a timely and convincing motivation for the need to protect DNS - I believe this motivation will significantly increase in the future, as the DNS infrastructure becomes utilised for more systems and purposes. This brings me to the next point - I was new to this topic (of privacy for DNS) and was not aware of the massive amount of efforts of this community to protect the privacy of DNS. Hence, I would like to thank all those that referred me to the works that I have not covered in my study. That draft was a ``first stab´´, and it focused on some of the schemes that I was aware of, that attempt to protect DNS via encryption. I intend to extend this work, in particular, I will also investigate the schemes that I was not aware of, and will add appropriate citations. Many thanks for sending those to me. @Stephane: many thanks for your comments. Please see response below. On Wed, Sep 24, 2014 at 3:57 PM, Stephane Bortzmeyer <[email protected]> wrote: > On Tue, Sep 23, 2014 at 05:48:31PM +0200, > Haya Shulman <[email protected]> wrote > a message of 15002 lines which said: > > > Dear members of the DNS privacy list, I recently did some work on > > the privacy of DNS via encryption, where I investigated the > > challenges with this approach. I would very much appreciate your > > comments, feedback and thoughts. > > Thanks for the interesting paper, I learned many things. But I > disagree with the general conclusion (which can be summarized as > "encryption is almost useless") for the following reasons. > [SH] I am concerned that the conclusion of the paper may have been misinterpreted, I will try to clarify the text. > You say "it [DNS encryption] does not fully solve the privacy > problem". I wonder if there is even one security technique which fully > solves a problem. Security is mitigating the risks, not dreaming of > suppressing them. It is even more so for privacy: computers and > networks leak a lot of information and we try to limit the leak, not > to plug all the holes. The real question is not "does solution X fully > solve the problem?" because the answer is almost always no, but "does > solution X make life and work more difficult for the attacker, at a > reasonable cost for the defender?" > > [SH] I agree with you that encryption of DNS packets imposes further difficulties on the attackers - the paper does not argue otherwise. What imho the work shows, is that a determined attacker, that expends the required amount of time and efforts, may still be able to learn sensitive information, which encryption attempts to hide. So, what I think the result means, is that someone who is really concerned with hiding the queries, should be aware of the potential leaks. > > > Also, I don't think that anyone suggested that encryption alone would > solve the DNS privacy problem. Following RFC 6973, we can say there > are two legs on which privacy walks: minimizing the data and > encrypting it. We need both. In the case of DNS, privacy will also > require things like QNAME minimization and local caching (caching > resolver in the users's premises or on its very own machine, may be > forwarding to bigger caches outside). So, saying that encryption alone > won't solve the problem will be no surprise for the readers of RFC > 6973. > [SH] Thank you for pointing this out, I will clarify this in the writeup. > > For your argument that DNS encryption would be a disruption for the > DNS, you say "the name servers of Alexa and TLDs have not adopted them > [encryption techniques]". Of course: none of these techniques is > standardized (and most are very recent and still untested). Speaking > for my employer, AFNIC would probably not deploy something that is not > at least on the standardization path (we may test it on less important > services). It is therefore unfair to criticize encryption on that > basis. > > [SH] This is an excellent point. The fact that the defences are not yet deployed was exactly why I investigated them - they are not yet deployed/standardised, so not to late to check if something can be adjusted. Changing standards is also more difficult, and less efficient. The history shows that changing the standards, during the deployment phase when the obstacles are discovered, causes confusion, extra efforts, addtional deployment cycles, failures, and inevitably negative attitude towards the proposed defence among the operational community, eventually resulting in impeded adoption. So I hope that you will not take this work as an attempt to criticise the efforts for encryption of DNS, but merely as a study of the involved challenges, and the potential limits on the security guarantees of this approach. > Speaking of deployment, you say things like "approximately 38% of > 50K-top Alexa domains and 12% of TLDs are configured in the following > way: the IP address of an authoritative name server belongs to a > recursive DNS resolver". That's not a good argument: DNS encryption is > new and deployment will take time. "Weak links" like TLD with a RAN as > a name server will disappear with time. Bad practices today should not > be used as a reason to avoid improving the privacy. > [SH] My impression is that there is an increasing tendency to outsource services. But, maybe this practice (of running RANSes) will disappear. But the work only focused on studying the existing infrastructure, so maybe one of the outcomes is to get rid of RANSes. I ran a small survey and I found that many of the network operators of domains that use RANSes are actually not aware of this. > > When you write "As we show, the existing proposals for encryption of > DNS packets between the resolvers and the name servers (settings (1) > and (3) in Figure 1) would not be effective in the RANS > configuration", I'm not impressed. Apart from a few big services like > OpenDNS, RANS are almost always unmanaged and abandoned configuration > errors. The fact that a solution does not work for them is not a big > problem. > [SH] I found ISPs in the US and other (security aware) networks in the US that support this configurations. So, I do not think that it is reasonable to claim that this practice applies only to security oblivious and mismanaged networks. > > For your other argument that leaks give sufficient information to the > eavesdroppers, you say "[leaks] which may enable an attacker to learn > the encrypted DNS content" and later "the attacker can accurately > guess which domain is accessed". You made a big step from "DNS > content" to "domain". DNS content (the full QNAME) is more than just > the domain (by which I assume you mean "registered domain", not > "domain name" in the usual DNS meaning). Without encryption, Eve, > sniffing example.com's name servers, can see that Alice requested > _bittorrent-tracker._tcp.example.com or bob-computer.example.com. With > encryption, if example.com is the only one present on the name > servers, Eve will just know that Alice requested > <something>.example.com. The difference is important and it is even > bigger for a TLD: if Eve manages to sniff AFNIC's name server's > traffic, encryption will limit her to learn that Alice is interested > in <something>.fr, a big win over the current situation. > > [SH] You are correct, the discovery proceeds in two steps: one discovering the domain using the transitive trust dependencies and another also utilises other side channels, such as the responses' size, to infer the requested record within the domain. I will check if this should be clarifed in the paper. > For the interesting analysis in 3.2.2 about dependencies, an unstated > assumption is that the cache is cold. If it is not, the attacker will > have much less queries to use for his/her analysis. You mention the > possibility that the attacker clears the cache by various means but > you apparently did not test them (I doubt that BIND or Unbound will > move the NS records of .com out of the cache just because there have > been many requests for somethingNNNN.example.org). Anyway, clearing > the cache of the victim is an active attack and protecting against > passive attackers would be, in my opinion, already a good thing. > > [SH] This is correct, I used a cold cache, and I tested with Unbound and Bind. Regarding com - this is less interesting leakage wise, since most ``interesting´´ domains are under com. In such cases, the patterns introduced by domains lower in the DNS hierarchy is more relevant. BTW, I do think that this attack would require a significant effort from the attacker, but it still does not elimitate the fact that there are leaks that can be exploited by the attackers. In this work I did not consider the question whether the attackers would bother to do this and which attackers would bother to do this. > There is a technical error in the analysis iof zakon.kz in 4.1: > resolvers will send a request without the RD bit and, therefore, > Google Public DNS won't answer it: > [SH] This is correct, when the RD is no set it would respond from the cache. I tested from various vantage points and all 8.8.8.8 hosts had that entry cached. > > % dig +norec @8.8.8.8 A zakon.kz > > ; <<>> DiG 9.9.5-4-Debian <<>> +norec @8.8.8.8 A zakon.kz > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40942 > ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;zakon.kz. IN A > > ;; Query time: 6 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Sep 24 15:52:26 CEST 2014 > ;; MSG SIZE rcvd: 37 > > So, the configuration of this domain is most certainly a technical > error, not a trick to leverage the cache of Google Public DNS. > Best regards. -- Haya Shulman Technische Universität Darmstadt FB Informatik <https://www.informatik.tu-darmstadt.de/>/EC-SPRIDE <http://www.ec-spride.de/>/CASED <http://www.cased.de/>/CROSSING <https://www.crossing.tu-darmstadt.de/en/crossing/project-areas/s-solutions/s3-privacy-preserving-access-and-verifiable-utilization/> Mornewegstr. 30, 64293 Darmstadt Tel. +49 6151 16-75540 sites.google.com/site/hayashulman
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
