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. 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?" 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. 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. 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. 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. 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. 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. 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: % 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.
signature.asc
Description: Digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
