Why can't we use DNS for distributing SSL certificates?

Most low-cost SSL certificate providers really only verify that you control a domain name. For those types of certificates, rather than pay a third party to verify that I control the DNS records for the domain, why not "sign" the certificate in DNS? If I generate a keypair on a server and publish the same public key in DNS for the hostname, I'd think that would be an equivalent level of security.

I see two problems with the design, but both seem minimal:

1. EA certificates and the higher-level certs that verify personal/corporate details can't be done this way. Organizations wishing to pay to get the green bar in browsers are free to continue doing so.
2. A malicious network with rogue DNS servers could redirect you to both a different hostname and a different trusted SSL certificate. Perhaps DNSSEC could take care of this repudiation problem?

I'm not aware of any browsers implementing something like this, but it seems like it would be a good method to at least get a trusted, encrypted connection without displaying the dreaded "Untrusted certificate" dialog. Aside from the issues I noted above and existing commercial certification authorities fighting the idea, are there any other reasons doing this would be a bad idea?

Solution 1:

It's already perfectly possible to encode an X.509 certificate inside a DNS Record - look at the CERT record type from RFC 4398.

The main reason it's not being done in anger much is because the transport mechanism isn't yet secure. This will change dramatically later this year when the root zone gets DNSSEC signed and as more and more TLDs support DNSSEC.

DNS query size (as mentioned elsewhere) is also a concern, although it's worth noting that the CERT RR also allows you to simply store the URL from which the real X.509 certificate can be downloaded. At this point there's something of a chicken and egg problem, though...

Solution 2:

SSL certificates are supposed to validate the identity of the site, so that the end user can be sure their request hasn't been diverted by a poisoned DNS server, bogus BGP broadcast, or other dirty trick that would also allow a bogus certificate served from DNS to look valid.

I say "supposed to" because then everything got watered down by "instant" certificates that prove nothing in particular, and to be honest I think browser vendors should either display the "untrusted certificate" warning for all unaudited certificates, or go ahead and allow self-signed certificates without prompting. The status quo is inconsistent.

Solution 3:

Since I asked this question years ago, there's been some positive development towards making this a reality. The combination of DNSSEC to secure your DNS with published TLS certificates in DNS allows this goal. Google Chrome has supported DNSSEC-stapled certificates for a while now, and now RFC6698 DNS-Based Authentication of Named Entities (DANE) is an attempt to standardize this support.

It'll be a few more years before the browser support for this is widespread, but I'm looking forward to it.

Solution 4:

The lack of standardisation, and the additional management overhead (much easier to just drop a key/cert on a machine than have to also add a key -- which is likely to be quite long and hence whack up against the UDP packet limit) are the things that kill this from a practical perspective. The lack of a secured DNS is slightly concerning, but for low-value targets it's not really a practical reduction in security. For internal services, though, we just import our own CA certificate so you don't really gain anything there, and any public site that needs SSL will want a "real" certificate anyway.

I'd expect to see massive backlash and FUD from the commercial certificate providers if something like this were to be seriously pushed (RFC drafts, reference implementations, etc) -- like any parasite, they get awfully annoyed when their cash cow looks like it might get slaughtered.