4

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?

5 Answers 5

5

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...

1
  • 3
    Now that DANE exists, ths answer should be edited...
    – bortzmeyer
    Oct 21, 2012 at 19:24
3

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.

1
  • 1
    Which "instant" certificates don't prove anything that are also trusted by browsers? There are domain control validation certificates, which indeed do not prove your entity as an organization, but the certificates themselves also don't claim to (the relevant sections of the CSR are ignored). However, they do prove (with varying rigor) that whoever presents the certificate does control the domain name. Are there CAs in practice that are trusted but don't even validate domain control? Mar 24, 2014 at 19:20
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.

1

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.

0

Maybe it is better to keep things simple - i.e. not make DNS do more than it is supposed to. I am kind of wary on adding stuff especially when it comes to security. Sometimes less is more. The main reason behind my thinking is because DNS and SSL are not in the same domain and do not have similar functionality nor purpose.

1
  • to be frank, I would downvote but I merely disagree. it's just as disjointed having to deal with SSL in HTTP but it is a much saner process to deal with them at the level of domain resolution. Certificates are naturally coupled with domains, and in the scope of domains. It also provides an incentive to create secure validation for authoritative DNS servers Nov 19, 2018 at 3:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .