> http://sockpuppet.org/blog/2015/01/15/against-dnssec/ > http://sockpuppet.org/stuff/dnssec-qa.html > https://www.imperialviolet.org/2015/01/17/notdane.html
Yawn - those were all terrible articles. To summarise their points: "NSA is bad, some DNS servers are out of date, DNSSEC may be still using shorter 1024bit RSA key lengths (hmm... much like TLS then)" The trouble is: Just because something isn't perfect, doesn't make it a bad idea. Certificates are not perfect, but they are not a bad idea. Putting certificate thumbprints in DNS is not perfect, but it's not half a *good* idea. Think about it: if your completely clear-text, unauthenticated DNS connection is compromised, then your browser is going to go to the wrong server anyway. If it goes to the wrong server, so will your email, as will the identity verification messages from your CA. Your browser needs to retrieve A and AAAA addresses from DNS anyway, so why not pull TLSA certificate hashes at the same time? Even without DNSSEC, this could only improve things. Casepoint, *absolutely* due to the frankly incomprehensible refusal to do this: http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/ There is nothing you can do to fix this with traditional X509, or any single chain of trust. You need multiple, independent proofs of identity. A combination of X509 and a number of different signed DNS providers seem like a good way to approach this. Finally - you can audit DNSSEC/TLSA responses programmatically as the response records are cached publicly in globally dispersed DNS servers, it's really hard to do the equivalent of "send a different chain when IP address 1.2.3.4 connects". I have my own opinions why TLSA certificate pinning records are not being checked and, having written an implementation myself, I can guarantee you that it isn't due to any technical complexity. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform