undefined | Better HN

0 pointsmike_hearn3y ago0 comments

DNSSEC is however the only way you can make TLS really work. The whole TLS ecosystem is dependent on CAs that are basically just a giant hack. They're signing a statement that they did a bunch of DNS resolutions at a point in time from different network vantage points (maybe, hopefully), and got consistent answers. DNSSEC+DANE lets you get the actual data you want (domain name->public key binding) from the root source, without needing the complicated middlemen.

0 comments

mike_d3y ago

DNSSEC+DANE is an affirmation by the United States government that you have followed a chain to an answer about a certificate pinning. Handshake (www.handshake.org, Trigger warning: crypto) will give you what you are talking about (CA non-reliance) anchored in the owner of the website itself.

If you aren't a fan of DV certificates (as you point out verified by resolution), you can always restrict your trust store to only CA certificates that sign EV certificates (verified by business records).

cryptonector3y ago

The root zone doesn't change often. You can pin . or even run your own private . with pinned . content if you don't trust the root.

If you do, then you get MITM protection.

If you don't, but choose to use QName minimization, you still get a modicum of MITM protection: because the attacker would have to choose to get in the middle without having enough knowledge of whether a particular upcoming TLS connection (or whatever) will be of particular interest.

Really, DNSSEC is infinitely better than the WebPKI, even WebPKI+CT, especially when DNSSEC clients use QName minimization, and even more so when clients pin copies of . from time to time.

j / k navigate · click thread line to collapse