3 ms·

DNS is even more centralized and tied to governments than CA's are.

cryptonector 8y ago
The WebPKI is easy to compromise because there are so many CAs and NameConstraints cannot be reliably used so the whole thing is not hierarchical. Certificate Transparency (CT) provides the ability to detect some CA abuses, but is not a magic bullet. DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult. DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed. So at least as to non-nation-state actors, DANE is already more secure than the WebPKI. QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones. In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.
- JoshTriplett 8y ago
  > NameConstraints cannot be reliably used I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".

The WebPKI is easy to compromise because there are so many CAs and NameConstraints cannot be reliably used so the whole thing is not hierarchical. Certificate Transparency (CT) provides the ability to detect some CA abuses, but is not a magic bullet. DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult. DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed. So at least as to non-nation-state actors, DANE is already more secure than the WebPKI. QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones. In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.

JoshTriplett 8y ago
> NameConstraints cannot be reliably used I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".