On Nov 28, 2013, at 11:10 AM, Paul Wouters wrote: > 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.
If the query is done via validated DNSSEC then that would defeat the MITM attack (this is mentioned in the draft). One problem with EDNS is that the RFC explicitly prohibits caching the results and I think that being able to cache the records will help avoid superfluous chatter on the network. > > 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. The idea here is that if a TLD and the delegated domains support confidential DNS then you could have a fully confidential query. I agree that this is a big IF, not quite as big as the DNSSEC signing problem but certainly a significant concern. > > 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) This is also a problem with multi-node name server footprints running unicast services as well. Worst case it would result in having to negotiate a secret with multiple name servers. In practice many load balancers use a hash to deliver traffic to the name servers in large footprints so this might be less problematic that at first appears. In cases where a load balancer is using a round robin algorithm this has poor characteristics. > > Paul > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
