The DNS-Based Authentication of Named Entities Transport Layer Security Protocol

Why are the organizations who can sign TLDs, or the DNS administrators who manages names under those TLDs, somehow more trustworthy than CAs? Some of the most desirable TLDs today are assigned to random governments by pure accident of fate and orthography. That problem is only getting worse now that the TLD namespace has been put up to the highest bidder.

The monolothic CA model has largely failed, and this draft merely seeks to reorganize it. Apart from "not needing to do business with CAs", that's the only value provided by DANE: your DNS administrators are now your CAs.

This isn't a win; it's a push.

In the short term, the untrustworthy CA problem can be addressed tactically through pinning, which provides key continuity. TACK is a protocol proposed by Trevor Perrin and Moxie Marlinspike to do that using only the insecure DNS we have now.

Over the long term, we need to engage with the fact that this is a UX problem, not a protocol problem. We haven't figured out how to encode the policy decisions we are requiring users to make into browser UIs. Moxie Marlinspike's Convergence system, which is a step towards a web-of-trust style peer-to-peer verification system (it would allow, say, the EFF to create a trust anchor for its followers), is one example of a genuine rethinking of the Internet trust model.

Taking the trust model we have now and baking it into a core Internet protocol seems like exactly the wrong thing to do. Centralized PKI isn't working. The right response isn't "double down on PKI".

How can DANE ever work if DNS (including DNSSEC) is an unencrypted protocol? Doesn't this mean that the moment you get a response to a DNS query the a malicious network could return orchestrated nonsense?

It looks like something like DNSCurve [1] would be needed, though Paul Vixie stated [2]:

  [...] the problems DNSCurve actually does solve are pretty well solved by UDP source port randomization and will be entirely eradicated by DNSSEC [...]

How does it solve the encryption problem?

[1] http://dnscurve.org/

[2] http://www.isc.org/community/blog/201002/whither-dnscurve

It's too bad it's based on DNSSEC. There's too many flaws and roadblocks for widespread adoption. If there was a compelling requirement for its use maybe it would get implemented everywhere in a number of years.

The biggest problem [to me] with relying on DNSSEC in current day systems is the non-verifying stub resolver in certain operating systems, which allows for a man in the middle attack at the client's first hop. https://tools.ietf.org/html/rfc4033#section-7