The DNS-Based Authentication of Named Entities Transport Layer Security Protocol(tools.ietf.org)
tools.ietf.org
The DNS-Based Authentication of Named Entities Transport Layer Security Protocol
https://tools.ietf.org/html/rfc6698
5 comments
Does your decentralized ideal apply to the whole Internet, or just TLD signing and such? In other words, do you believe we'd be better off without a DNS root zone? I know there's Freenet, so I guess another question is whether you think that shift could ever become mainstream.
If so, I'd love a reply.
If not, I'd love a reply. And! And then... this DANE shift would not be such a bad thing, right? You have the hierarchy anyway, so why not have the option of securely publishing [1] your public keys. By the time you have registered your domain and paid all your fees, you might as well!
As for the potentially insecure signing of some TLDs, isn't it partly due to the decentralized nature of the ccTLDs? From a security perspective people may have to learn to trust more .com domains with a green lock than, say, .ly.
[1] I'm purposely using this loaded term, as I'm full of doubt and confusion, hoping to provoke the master and get more thoughts! Refer, for instance, to my TL comment in this thread.
If so, I'd love a reply.
If not, I'd love a reply. And! And then... this DANE shift would not be such a bad thing, right? You have the hierarchy anyway, so why not have the option of securely publishing [1] your public keys. By the time you have registered your domain and paid all your fees, you might as well!
As for the potentially insecure signing of some TLDs, isn't it partly due to the decentralized nature of the ccTLDs? From a security perspective people may have to learn to trust more .com domains with a green lock than, say, .ly.
[1] I'm purposely using this loaded term, as I'm full of doubt and confusion, hoping to provoke the master and get more thoughts! Refer, for instance, to my TL comment in this thread.
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]:
[1] http://dnscurve.org/
[2] http://www.isc.org/community/blog/201002/whither-dnscurve
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 [...]
[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
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
> It's too bad it's based on DNSSEC.
Yup, that about covers it. My favorite DNSSEC feature is TLDs and .govs continually fucking it up.
More seriously this vs CAs is just a philosophy argument. CAs are a club of grandfathered "trusted" parties. This is single source .govs and other TLDs for the trusted party. Yay. Currently I, personally, can choose to not trust Verisign and go with another CA. In this world I can trust Verisign, because they own .com, or go fuck myself. Clearly a win.
Oh well soon enough some jackass will put this in a FISMA or PCI DSS requirement and everyone will support it anyways.
Yup, that about covers it. My favorite DNSSEC feature is TLDs and .govs continually fucking it up.
More seriously this vs CAs is just a philosophy argument. CAs are a club of grandfathered "trusted" parties. This is single source .govs and other TLDs for the trusted party. Yay. Currently I, personally, can choose to not trust Verisign and go with another CA. In this world I can trust Verisign, because they own .com, or go fuck myself. Clearly a win.
Oh well soon enough some jackass will put this in a FISMA or PCI DSS requirement and everyone will support it anyways.
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".