DNSSEC replaces one hierarchical PKI (the CA system) with another hierarchical PKI (the DNSSEC tree).
Ironically, the dominant provider in both PKIs happens to be Verisign.
One difference between the two PKIs is that the CA system admits to many different CAs, and to browser and even end-user control over which CAs are trustworthy. On the other hand, DNSSEC bakes its authorities into the core of the Internet. Don't like Verisign? Tough shit. A pithier way to say the same thing: Ghaddafi's Libya would at one point have been BIT.LY's "CA" in a DNSSEC world.
The role of any PKI authority in the HTTPS/TLS ecology will diminish soon with something like TACK, which integrates key continuity with the TLS PKI. TACK doesn't require DNSSEC, but allows websites to "pin" their certificates into browsers so that even if Iran or China hacks your trust anchor, your site can overrule them. This is exactly the scheme Google uses today to protect its properties: no DNS record or CA signature will convince Chrome that you are the real GMail.
The short answer to "replacing the CAs" as a use case for DNSSEC is that DNSSEC doesn't change the model or the security characteristics of HTTPS/TLS; it's at best a lateral move. But there are specific ways in which it makes HTTPS/TLS trust problems worse, and even more ways that it introduces reliability problems.
Yes, but that other hierarchical PKI is one that we already trust almost everywhere: although extended validation SSL certificates give you an idea of the legal entity in control of the site, in general the only thing it means to be the legitimate owner of a domain is for the DNS roots to recognize you as such. In particular, I don't know any system other than certificate pinning in which a rogue operator of .ly wouldn't be able to get a certificate for bit.ly, or even if that would be considered inherently illegitimate; I like the idea of alternative, decentralized DNS roots like .bit, but fixed authorities are what we're stuck with today. Making the entity that you trust the only entity that you trust is a strict improvement.
And yes, certificate pinning is an exception, making the browser vendor the CA for a small number of domains, but Convergence and other systems depend on the DNS, and TACK only helps on subsequent visits to an already visited site.
I dispute that it's strictly better to have one trust anchor in the TLS PKI, because it matters very much who that trust anchor is and what their incentives are. Verisign won't be ousted from the top of the DNSSEC PKI, no matter what. CA's can fold.
Why are we required to assume that anyone who answers a plaintext email from a domain must be issued the certificate corresponding to that domain? Why can't we authenticate the issuance of new certificates out-of-band? We could address that problem without even requiring browser modifications.
Also, in a TACK+TLS/CA world, Libya could not have surreptitiously swapped out BIT.LY's certificate. In a TACK+TLS+DNSSEC world, they can; stub resolvers don't verify signatures in DNSSEC.
Ultimately, what we need over the long term is a system like Convergence to allow trusted third parties to vouch for CAs, and for users to choose from among trusted third parties who they want to vouch for CAs. This is largely a UI/UX problem, and it's orthogonal to whether HTTPS trust anchors come from X.509 or DNS.
It feels like the very best argument that can be made for DNSSEC as a CA alternative is that it doesn't make things worse. (I personally think that it makes things much worse, but stipulate otherwise here). But it's tremendously expensive and brittle, addresses mostly the solved part of the problem, and does nothing to help the major unsolved part of HTTPS trust.
> Why can't we authenticate the issuance of new certificates out-of-band?
Authenticate with who, Verisign (the ones that have the authority to determine who owns the domain)? I guess making it out of band alleviates some situations where Verisign gets hacked (but not where Verisign is untrustworthy, which you could argue is the case for recent US domain seizures), but the number of domains requiring certificates is high enough that they're just going to end up checking the same database.
> Also, in a TACK+TLS/CA world, Libya could not have surreptitiously swapped out BIT.LY's certificate. In a TACK+TLS+DNSSEC world, they can; stub resolvers don't verify signatures in DNSSEC.
Huh? In a TLS/CA world, Libya could get a legitimate new certificate (although I guess this could be noisier); in a TLS+DNSSEC world, Libya could produce a valid signature. TACK has the same effect on both, protecting some but not all users; invalid DNSSEC signatures are irrelevant. (But in general, the stub resolver issue is one such practical problem that I'm here not worrying about.)
As I said, I believe that Convergence doesn't really help as long as the trusted third parties are validating using DNS, and the only way around that is a new DNS root designed from the start to be decentralized and cryptographically secure.
(We're getting far out to the margin of the thread, and as we do so, I get more and more terse, if not in language then in thinking).
Regarding your first question:
To a first approximation, everyone that needs a TLS certificate already has one.
The concern about authenticating requests for certificates is about attempts to get certificates issued against entities that already attest to having them.
An entity that already has a cert can authenticate new requests for different certs; for instance, they can put a PGP or S/MIME key on file with the CA, and that key can be used to authenticate new requests.
Actually, every tool in the web authentication toolbox, from S/MIME through 2-factor auth keys, is fully available to CA authentication, which is a good thing.
So the question then is, why should ability to answer an email sent to a domain trump every other authentication mechanism we could use instead?
To your second question: my point is just that Libya can more quietly hijack BIT.LY under DNSSEC than they can under an HTTPS CA model.
I agree that we need better trust anchors for peer-to-peer verification than DNS.
Ironically, the dominant provider in both PKIs happens to be Verisign.
One difference between the two PKIs is that the CA system admits to many different CAs, and to browser and even end-user control over which CAs are trustworthy. On the other hand, DNSSEC bakes its authorities into the core of the Internet. Don't like Verisign? Tough shit. A pithier way to say the same thing: Ghaddafi's Libya would at one point have been BIT.LY's "CA" in a DNSSEC world.
The role of any PKI authority in the HTTPS/TLS ecology will diminish soon with something like TACK, which integrates key continuity with the TLS PKI. TACK doesn't require DNSSEC, but allows websites to "pin" their certificates into browsers so that even if Iran or China hacks your trust anchor, your site can overrule them. This is exactly the scheme Google uses today to protect its properties: no DNS record or CA signature will convince Chrome that you are the real GMail.
The short answer to "replacing the CAs" as a use case for DNSSEC is that DNSSEC doesn't change the model or the security characteristics of HTTPS/TLS; it's at best a lateral move. But there are specific ways in which it makes HTTPS/TLS trust problems worse, and even more ways that it introduces reliability problems.