Why not validate self signed certificates through DNS-record instead of letsencrypt

I was just wondering. We use a lot of SSL certificates. Nowadays, we almost exclusively use letsencrypt (thanks!). The bottom line of these certificates is, that proof of ownership of the domain name(s) on the certificate comes from the power to manipulate either the DNS records or the website under these domains. The DNS proof comes from adding some key (given by letsencrypt) as a TXT record to the DNS.

So, IF it is enough proof to be able to change the DNS records for a domain, why not use self signed certificates with the fingerprint in the DNS?

I would say this gives exactly the same amount of trust as the DNS based procedure of letsencrypt (and other CA's):

1. Create a self signed CA (just follow the steps of the various how to's)
2. Create a certificate for some domain(s)
3. Sign the certificate from step 2 with the CA from step 1. You now have a basic certificate, signed by a non trusted CA
4. Add a TXT (or dedicated) record to the DNS of each of the domains, stating: we signed the certificate of this domain with this CA. Like: 'CA=-fingerpint of CA-'
5. A browser downloads the certificate and verifies it by comparing the fingerprint of the CA / the CA certificate with the data in the DNS for the given domain.

This would make it possible to create trusted self signed certificates without third party interference, of the same trust level as any basic SSL certificate. As long as you have access to the DNS, your certificate is valid. One could even add some DNSSEC like encryption, of make a hash out of the CA plus the SOA-record, to make sure the trust disappears on changes in the DNS record.

Has this been considered before?

Jelmer

Solution 1:

The basic infrastructure, that would make this possible, exists and is called DNS-Based Authentication of Named Entities (DANE) and specified in RFC6698. It works by means of a TLSA resource record, that specifies the certificate or its public key of the end entity or one of its CAs in the chain (There are actually four different types, see the RFC for details).

Adoption

DANE has however not seen widespread adoption yet. VeriSign monitors DNSSEC and DANE adoption and tracks its growth over time:

For comparison, according to VeriSign, there exists about 2.7 million DNS zones, so that means that a bit more than 1% of all zones have at least one TLSA record.

I can't give any authoritative answer, why DANE, but here are my speculations:

DANE suffers from the same problem as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). In order to verify the validity of a presented certificate, a third party must be contacted. Hanno Böck gives a good overview, why this is a big problem in practice. It boils down to the issue of what to do, when you can't reach the third party. Browser vendors opted to soft-fail (aka permit) in this case, which made the whole thing rather pointless and Chrome ultimately decided to disable OCSP in 2012.

DNSSEC

Arguably DNS offers much better availability than the CRL and OCSP servers of CAs, but it still makes offline verification impossible. In addition DANE, should only be used in conjunction with DNSSEC. As normal DNS operates over unauthenticated UDP, it is quite prone to forgery, MITM attacks, etc. The adoption of DNSSEC is much better than the adoption of DANE, but is still far from ubiquitous.

And with DNSSEC we run again into to the soft-fail problem. To the best of my knowledge no major server/client operating systems provides a validating DNSSEC resolver by default.

Then there is also the issue of revocation. DNSSEC has no revocation mechanism and relies on short lived keys instead.

Software Support

All participating software must implement DANE support.

In theory, you might think, that this would be the job of crypto libraries and application developers wouldn't have to do much, but the fact is, cryptographic libraries typically only provide primitives and applications have to do a lot of configuration and setup themselves (and there unfortunately many ways to get things wrong).

I'm not aware, that any major web server (e.g. Apache or nginx) for example implemented DANE or has plans to do it. Web servers are of particular importance here, because more and more stuff is build on web technologies and therefore they are often the first, where things get implemented.

When we look at CRL, OCSP, and OCSP Stapling as comparison, we might be able to infer how the DANE adoption story will go. Only some of the applications, which use OpenSSL, libnss, GnuTLS, etc. support these features. It took a while for major software like Apache or nginx to support it and again referring back to Hanno Böck's article, they got it wrong and their implementation is flawed. Other major software projects, like Postfix or Dovecot don't support OCSP and have very limited CRL functionality, basically pointing to a file in the file system (which isn't necessarily re-read regulary, so you would have to reload your server manually etc). Keep in mind that these are projects, which frequently use TLS. Then you can start looking at things, where TLS is much less common, like PostgreSQL/MySQL for example and maybe they offer CRLs at best.

So I've not even modern web servers implement it and most other software hasn't even got around to implement OCSP and CRL, good luck with your 5 year enterprise application or appliance.

Potential Applications

So where could you actually use DANE? As of now, not on general Internet. If you control the server and the client, maybe its an option, but in this case, you can often resort to Public-Key Pinning.

In the mail space, DANE is getting some traction, because SMTP did not have any kind of authenticated transport encryption for the longest time. SMTP servers did sometimes use TLS between each other, but did not verify that the names in the certificates actually matched, they are now starting to check this through DANE.

Solution 2:

Different types of certificate validation procedures

With the regular CA-signed certificates, there are several levels of certificate validation:

• Domain Validation (DV)
  Only domain name ownership is validated, only the domain name is shown as "Subject" in the certificate
• Organization Validation (OV)
  Domain name and owner name are validated, domain name and owner name show as "Subject" in the certificate
• Extended Validation (EV)
  More rigorous validation of the owner entity, domain name and owner name show as "Subject" in the certificate, green bar with owner name

The process that you describe, and propose a replacement for, only applies to the lowest level, Domain Validation (DV).

DV is the level where the validation is relatively straightforward to automate, such as what LetsEncrypt have done, and provides similar level of trust as what DNS could provide if it was used as the sole source for a trust-anchor (UI implications, cert may be trusted but contain additional data that is by no means validated).

DNS-Based Authentication of Named Entities (DANE)

DANE builds on top of DNSSEC (as DNS data authenticity is crucial) to publish trust-anchor information for TLS clients in DNS.

It uses the TLSA RR type and can be used to identify either the certificate or the public key (selector) of either the end entity or the CA, with or without also requiring the regular certificate chain validation to succeed (cert usage) and how the cert/key data is represented in the record (matching type).

The TLSA record owner name has a prefix which indicates the port and protocol (eg _443._tcp) and the RData indicates the cert usage, selector and matching type modes in addition to the cert/key data to match. See section 2.1 of RFC6698 for the specifics of these parameters.

A TLSA record can for example look like this:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

With usage modes 2 or 3 (indicates use of the TLSA trust-anchor alone), a DANE-aware client would accept a certificate that is not signed by a generally trusted CA but which matches the TLSA record.
This is conceptually the same as what you propose in your question.

The catch? DANE-aware clients are currently more or less non-existent, one issue being that DNSSEC itself is not as widely deployed (especially validation on the client machine) as what would probably be required for DANE to take off. Likely a bit of a chicken-and-egg problem, considering that DANE is one of the first potentially big new use-cases that rely on authenticated DNS data.

There is a browser plugin that adds DNSSEC and DANE validation, other than that there's not much there that is anywhere near mainstream at this point. And, being a plugin rather than natively supported, it serves more as a proof-of-concept than anything else when it comes to general use.