(in)Security Analysis and Catastrophically bad Design: Re: [dnsext] DNSCurve Internet-Draft

[Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>]

Executive summary of the following:

a)  DNSCurve's design provides almost no practical enhancement to system security.

b)  DNSCurve's implementation guarantees substantial deployment problems due to transport issues, because it doesn't parse as DNS and never considered why 512B is a "magic number" for DNS on the network.

As a result, DNSCurve should be rejected with extreme prejudice!


a:

There is no threat ANALYSIS in the security considerations at all, rather just statements like:

>    DNSCurve only provides link-level security between a client-server
>    pair.  It does not attempt to ensure end-to-end security for queries
>    and responses relayed by untrusted DNS proxies and caches.


Lets start with integrity, which what really counts in DNS:  The problem, simply put, is that any conventional threat analysis shows that link level integrity is almost useless:

You have out of path attackers and in-path attackers, and attackers on the link between the client and the recursive resolver, and between the recursive resolver and the general Internet.

Against out of path attackers, we have robust defenses both universally implemented (port randomization), and proposed with some implementation (glue validation, 0x20, EDNS0-based).  Did we fail in this?  I'm actually pretty confident we haven't, because we've enumerated the space and properties.  An attacker has to SEE the traffic in order to attack a modern recursive resolver


Thus DNSCurve is only providing integrity against in-path adversaries, which exist between the resolver and authority.

The problem is, simply put, DNS doesn't exist in a vacuum, DNS integrity is part of the final protocol.  And the final protocol either also trivially vulnerable to an in-path adversary, so DNScurve only provides protection when the in-path adversary is NOT on the final path of the application.  Practically put, this is a rare case.

Worse, there is one in-path adversary that IS significant for DNS, because it is NOT on the final path for data: the recursive resolver!  We have witnessed resolvers delivering malicious results, both due to malcode and due to "legitimate" activity of the resolver operator (yes, we've seen ISPs MitM www.google.com in DNS!).  Yet DNSCurve, by design, provides no message integrity, which is what's needed to deal with bad recursive resolvers.

So DNSCurve's integrity benefits are almost trivially useless!


Worse, DNSCurve's CONFIDENTIALITY attempts are almost as useless:  Even assuming complete deployment, if you are monitoring either the final authority or the resolver's outgoing requests, because you know who is talking to whom, AND the structure of the DNS hierarchy, AND the size of the responses.  

Thus for DNS, traffic analysis will work wonders, ensuring that there is no real confidentiality except in rare cases.  And really, the confidentiality risk is from the recursive resolver itself, eg, with some recursive resolvers (eg, Google Public DNS) really existing for the purpose of datamining the query stream.  Thus the claims of confidentiality should be completely dropped: they don't actually exist worth squat.


Oh, and despite the obsession with reflector attacks, DNSCurve has no impact on this, because you can just do large response reflector attacks from open resolvers: DNSSEC's large replies actually provide very little benefit for someone intelligent conducting a DNS reflector attack.


It is this sort of security analysis which is missing from the DNSCurve draft and, if included, makes one realize just how useless DNSCurve is. 



B:

Additionally, the implementation is CATASTROPHICALLY bad.  And I do mean catastrophically, based on my experience in measuring the network with Netalyzr and (in progress) direct probing of recursive resolvers.


If the goal is to avoid malfunctioning middleboxes, making DNSCurve packets non-parseable is a disaster.  We can't tell between resolver and authority, but the path between client and the net is FULL FULL FULL of devices which will block DNS traffic that's not valid DNS.  

On port 53, you MUST parse as DNS if you want any hope of reliable delivery, PERIOD.


This is a far bigger problem than the 512B limit, which is very low (a couple percent) on the resolver->authority path and client->authority path, which DNSCurve has an unreasonable obsession with.  (A far bigger problem is fragmentation, which is more like 1400+ bytes in practice).  

Additionally, any path which has a 512B limit is due to a DNS-aware middlebox.  How do you think such middleboxes are going to react to a non-valid message on port 53?  

Thus DNSCurve's "small packet" obsession for reliability is defeated utterly by DNSCurve's message format, which does not parse as valid DNS, because the design never considered WHY 512B was a "magic limit" in the network for DNS!



Thus as an implementation, DNSCurve MUST NOT produce data that is not parseable as DNS, as that WILL be blocked with far greater probability than packets of over 512B in size.

Rather, the client key MUST be contained in an EDNS resource record (this is exactly what EDNS is for!), and the response from the server MUST be completely encapsulated into an EDNS resource record (so a response with 0 answer, 0 auth, 1 EDNS0 in the additional, with the additional being an encryption of the "real" DNS response), as this is far more likely to be passed by the net unhindered and actually can respect the EDNS MTU.


Of course, if you are going to do this, you might as well also define keys in a resource record type as well, and gee, what do you get?  Well, something either like DNSSEC (if you use signatures on data for end-to-end integrity) or Barwood's proposal (if you do on-the-wire integrity/confidentiality)




As a consequence, DNSCurve should be rejected with extreme prejudice, and I mean extreme prejudice:

The architecture provides almost a trivially small increase in aggregate security

The implementation is critically, and completely broken in its objective because it uses opaque MESSAGES rather than opaque resource records.