BTW, pls see below a clearer response on the last point.
On Wed, Sep 24, 2014 at 7:05 PM, Haya Shulman <[email protected]> wrote: > 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. > [SH] IMHO this may be an indication that this configuration is intentional and not a configuration error. > > > > >> >> % 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 > -- 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
