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

FYI

The exact same things can be said about DNSSEC. (no practical
enhancement to system security, substantial deployment problems), all
discussed in NTIA comments
[http://www.ntia.doc.gov/dns/comments/comment027.pdf] These DNSSEC flaws
have also been discussed on the IETF DNSOP and DNSEXT mailing lists.
[that is, until I was silenced by the Vixie/Cerf cabal.] The IETF is
aware of these serious DNSSEC flaws and have been covering them up for
several years.  Recently, the cache poisoning flaw I described has been
confirmed. That particular flaw is remarkable because DNSSEC was
conceived to PREVENT cache poisoning attacks.

An important difference between DNSCurve and DNSSEC is that DNSSEC also
enables a new and serious DDOS attack (as I described previously), while
I don't think DNSCurve can be so similarly abused.  There are several
more flaws in DNSSEC that aren't shared by DNSCurve. (previously 
described)

However, to some extent, Nicholas Weaver's criticism below is only
relevant to Dempsky's draft describing DNSCurve. For example, the lack
of discussion under security considerations.  I don't think it is the
case that DNSCurve hasn't been analyzed, but that Dempsky doesn't relate
the analysis.  While it would be a good idea to relate the analysis,
this is unfair criticism of Dempsky because DNSSEC documents also lack
similar analysis, and those documents actually missed the problems I
identified, even //after// I identified them.

Furthermore, Weaver's analysis is also incomplete. For example, the case
of out-of-path attackers is easily handled by TCP; no cyptography is
needed for that case.

Particularly amusing given recent discussion on this list is the
exclamation by Weaver: "yes, we've seen ISPs MitM www.google.com in
DNS!"  The ISP doing this is actually OpenDNS, Dempsky's employer.  Of
course, even with DNSSEC, the recursor can still "MitM" lookups very
simply by not implementing DNSSEC.  Since both proposals share this
defect (if it is one), it is unfair to criticize only one for this
alleged defect.  Seems there is a saying here that is revelant;  
something about a speck of dust vs a log in an eye that is relevant...

	--Dean


---------- Forwarded message ----------
Date: Wed, 3 Mar 2010 09:15:28 -0800
From: Nicholas Weaver <[email protected]>
To: Matthew Dempsky <[email protected]>
Cc: Nicholas Weaver <[email protected]>,
     IETF DNSEXT WG <[email protected]>
Subject: (in)Security Analysis and Catastrophically bad Design: Re:
    [dnsext] DNSCurve Internet-Draft



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.