On Thu, 28 Nov 2013, W.C.A. Wijngaards wrote:
I also heard that this is the place to discuss DNS privacy.
This is a generic problem people keep mentioning. We need some new WG for DNS extensions that's not operations. i was told this was going to be discussed at dnsops at ietf88 , but it did not happen.
http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-00 It supports opportunistic encryption, i.e. try to encrypt but fallback to insecure. This supports deployment immensely, because clean DNS paths are uncommon. It supports stateless operation. It uses UDP. It supports encryption for stub-to-cache and cache-to-authority.
Asking the LAN's resolver for a specific record (type ENCRYPT to QNAME ".") seems a bit dangerous. This is of course completely MITM-able, but I see no real other way to trust something fundamentally untrustworthy. So that's okay. But I fear too many of these queries might end up on AS112. I'd rather see an EDNS advertisement. For talking to AUTH servers, there is no reason to use QNAME ".". It could just query for some kind of ENCRYPT record in the zone, which can be authenticated with DNSSEC, and then becomes resistant to MITM. Even if that means you once traverse top down to collect the various TLD ENCRYPT keys. DNS already has a lot of known plaintext. Having a padding flag that an attacker can play with seems dangerous too. We've seen too many padding/oracle attacks. In general, I would prefer that the DNS people don't invent their own crypto scheme, and use something that has seen a lot more scrutiny. If (D)TLS is too expensive, than perhaps we should look around and see how other people solved this in the past. But I think the "too expensive" is specific to real authoritative servers, and for instance would never be an issue for a LAN/ISP resolver - a reason to think of these two problems in two separate documents with possibly different solutions. Additionally, encrypting to authoritative servers seems to not make _that_ much sense to me. Remember, when I need to know www.nohats.ca, I already tell the .ca nameserver the entire QNAME before I get the referral. While I see value in LAN/ISP dns cache encryption, I think encryption of DNS globally is a whole different matter. Encrypting our individual transactions might not gain us much at all. This scheme also depends on state between queries. There are dangers with anycast where specifically the different nodes in different regions should NOT be using the same crypto key. (which makes storing the key in DNSSEC harder as well) Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
