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
Answer
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.
Attribution
Source : Link , Question Author : Jelmer Jellema , Answer Author : Community
