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

Question

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):

Create a self signed CA (just follow the steps of the various how to's)
Create a certificate for some domain(s)
Sign the certificate from step 2 with the CA from step 1. You now have a basic certificate, signed by a non trusted CA
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-'
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

Thanks Håkan! Through an update, I found the term DANE for this RFC. Last version of the RFC: https://tools.ietf.org/html/rfc7671 See also: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities (I will read it later). — Jelmer Jellema, Mar 05 '18 at 14:36
The "why not" is also covered in the RFC Håkan linked: without DNSSEC, the reliability of the entire model is compromised due to the vulnerabilities inherent to DNS. It should also be noted that DNSSEC does nothing to secure traffic between clients and recursive systems, which remains susceptible to man in the middle spoofing. — Andrew B, Mar 05 '18 at 15:43
Andrew, I see the problem with DNSSEC and MIDM, when DNSSEC is not forced for a domain, and forcing can only be done if each and every lookup is done by checking the root domain server for the tld. So the problem is: we want to authorize the use of some DV-certificate by having the owner state it's validity, but we cannot trust DNS because of it's hierarchical nature. The fact that DNS is vulnarable to spoofing and MIDM-attacks makes DV certificates sort of the external validation of a domain entry. Hmm, I'll keep thinking... — Jelmer Jellema, Mar 05 '18 at 20:17
Crossdupe https://security.stackexchange.com/questions/68504/storing-ssl-certificates-in-dns-records (2014) https://security.stackexchange.com/questions/23648/what-alternatives-are-there-to-the-existing-certificate-authority-system-for-ssl (2012) https://security.stackexchange.com/questions/6824/can-i-improve-website-security-by-storing-ssl-keys-in-dns-is-dnssec-required-a (2011) — dave_thompson_085, Mar 06 '18 at 05:44

score 18 · Answer 1 · edited Oct 07 '21 at 07:34

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.

Thank you Sebastian, your reaction is very helpful. Please see my and Andrew's comments under the OP. — Jelmer Jellema, Mar 05 '18 at 20:18
Why is it necessary for web servers to implement this? I could add a self signed cert to the apache config and put the fingerprint in the DNS myself, right? — Jelmer Jellema, Mar 05 '18 at 20:33
@JelmerJellema Right, the TLS server (eg web server) software does not need to be DANE-aware. It’s the TLS client (eg web browser) that needs to implement DANE. — Håkan Lindqvist, Mar 05 '18 at 22:07
There are also performance and scalability problems with DNSSEC vs. DNS: plain DNS can use "canned" responses but DNSSEC has to do cryptodance for every request, and there are a LOT of DNS requests flying around. Like, **a LOT** of DNS requests. — Joker_vD, Mar 05 '18 at 22:18
@Joker_vD DNSSEC signs the data, not the traffic. Ie, on the authoritative end you can sign your zone and not have more “cryptodance” for the lifetime of the signatures (or until you change zone data); it’s on the validator side (client side) that the per-uncached-request “cryptodance” needs to happen. Both the additional data and DNSSEC status fits the general caching model for DNS. — Håkan Lindqvist, Mar 05 '18 at 22:44
There are works to add the DNS chain of records, plus the associated DNSSEC material, inside a TLS handshake. See https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ and https://wiki.mozilla.org/Security/DNSSEC-TLS-details#Transmitting_the_DNSSEC_Chain This allows the client to validate things without having to do other DNS lookups. — Patrick Mevzek, Mar 06 '18 at 03:10
@Joker_vD "cryptodance for every request" : not true for the authoritative nameserver, it can pregenerate the signatures (see https://blog.cloudflare.com/dnssec-complexities-and-considerations/ for some discussion) and even if other modes of operation exists, but of course the recursive nameserver has to do cryptography if it wants to validate the answers it gets. — Patrick Mevzek, Mar 06 '18 at 03:13
@Joker_vD except of course if you do DNS over TLS or over HTTPS in which case the traffic will be encrypted which means cryptography on both ends to exchange data (which would itself be secured by DNSSEC). — Patrick Mevzek, Mar 06 '18 at 03:16

score 5 · Answer 2 · edited Oct 07 '21 at 07:34

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.

It could be done. It has been considered. It could still happen, but there hasn't been a lot of movement.

Thanks Håkan . As Andrew points out under my OP, there is a problem with DNS and DNSSEC, as DNSSEC is not forced (not even when the keys are in place at d the TLD DNS, I guess) DNS servers along the way could spoof the DANE information, right? So DNSSEC should be obligated for the DANE records to be valid, which in turn means each and every check must also check the keys at the TLD server. — Jelmer Jellema, Mar 05 '18 at 20:21
@JelmerJellema As I noted in my answer, DNSSEC needs to be validated on the client (not doing that is the problem Andrew pointed to) and only successfully validated signed TLSA records can be used. This problem you speak of is not a problem in terms of design, it's a problem in terms of support in mainstream software. — Håkan Lindqvist, Mar 05 '18 at 20:38
While not perfect, more and more recursive nameservers at ISPs or open ones, like 8.8.8.8 or 9.9.9.9 are doing DNSSEC validation. dnssec-trigger built on unbound and/or things like stubby would permit having full DNSSEC validation on the clients without necessarily a full validating DNS resolver at the client. But we are indeed far from that... — Patrick Mevzek, Mar 06 '18 at 03:22