DANE has been around for a few years now but still seems to be a bit of an underground topic. It hardly ever crops up in conversations I have with prospects and the fact it is reliant on DNSSEC, which takes a serious commitment to implement, makes me wonder if this is just another good idea that is going nowhere.
However, once you understand what DANE can do, it makes me wonder why more people aren’t implementing it. In fact DANE could be just the “killer app” that DNSSEC needs in order to make the implementation of DNSSEC a “no-brainer”.
So what is DANE and why could it be such a revolution?
DANE should not be confused with a not very famous nineties pop star, it actually stands for “DNS-Based Authentication of Named Entities” and was ratified in RFC 6698 way back in 2012.
DANE, at its simplest, allows the Internet to “do away” with certificate authorities and instead store SSL/TLS certificates as DNS records. These records can then be signed with DNSSEC to verify that they are authentic and have not been tampered with. Because DNSSEC relies on a chain of trust, your organisation can be responsible for storing, signing and revoking certificates and everyone else on the Internet can be confident that your certificates are valid because your DNSSEC enabled domain has been trusted by your parent delegating authority, who in turn has been trusted by their parent and so on all the way up to the DNS root.
This means there is no longer any need to maintain a list of trusted certificate authorities in your browser (or operating system) and is the reason why DANE is such a game changer.
Who do you trust?
Currently each browser or piece of software that establishes connections over SSL has to be able to validate the certificate that it is presented with. But how do you know if the certificate that is being presented is valid? Normally the certificate has been signed by an intermediate certificate authority (CA) that is trusted by a root CA – and you will have a list of the root CA’s stored in your browser (or operating system).
Currently, Chrome on my laptop (which uses the Windows certificate store) has 48 root CA’s listed, but many more are available via Windows Update (Microsoft has a 32 page PDF file here that lists them all). Different operating systems will have different mechanisms available to maintain the list of trusted root CA’s, but the problem is that with so many root CA’s being trusted it is difficult to be 100% confident that they are all genuine or have not been compromised, or are not being used to snoop on SSL traffic (see article “Hacked Certificate Authorities – Nothing Left to Trust”). You have no personal or business relationship with the providers of these root CA’s, yet you are trusting them with guarding your private information. Isn’t this a bit like giving everyone in your street a piece of paper with your Internet banking details on and hoping they don’t get burgled?
You also have very little control over which root CA is used to ultimately verify an SSL certificate. What if you visit a site and the certificate claims to be trusted by a root CA in China or Saudi Arabia? Microsoft’s root CA list in that PDF file I mentioned earlier does not list any root CA’s in Iraq/Iran/Syria/North Korea etc., but both China and Saudi Arabia operate root CA’s and both are well known proponents of Internet censorship. Would you be happy knowing that your SSL traffic could potentially be intercepted by the governments of these countries?
Because DANE removes the need to maintain and trust a list of root CA’s (whom you have no personal or business relationship with) it removes a lot of these “trust” issues. Your SSL/TLS certificates are signed by your DNSSEC private key, which you can change at your leisure, and your domain is trusted by your parent (with whom you have a business relationship with as they had to sign your “DS” records). Firstly people who need to validate your SSL/TLS certificates only need to trust the DNS root domain, and secondly, if someone manages to compromise your DNS domain, the DNS TLSA records (used to store the certificates) will not validate, causing browsers worldwide to issue certificate warnings and/or block access to the secure elements of your site.
Adoption, as usual, is the biggest challenge
Switching from a CA-based system to DANE is obviously a massive change, but there is a half-way house which might help, and that is to allow DANE to “nominate” a set of specifically trusted CA’s (using DNS TLSA records that have again been signed by DNSSEC). So the CA mechanism can still be used by client software (i.e. retrieve the certificate from a CA rather than via DNS), but DANE is just used to specify which CA’s should be used to validate your certificates. Another option is to use DANE to store a fingerprint of your certificates, so you can check that the certificate returned by the CA matches the fingerprint you have stored in DNS (i.e. a double-check that it has not been compromised).
The main problem at the moment however is one of support. Neither Internet Explorer nor Chrome provide native support for DANE, although a plug-in is available here. So web browsing will probably have to continue using the current “broken” trusted root CA-based system for the time being, but other use cases are appearing, notably secure delivery of email over TLS as supported in Postfix v2.11 and above (see interesting article discussing sending secure email using Postfix and DANE here). And of course, DNSSEC also needs to be deployed, which has its own set of challenges.
Maybe if Chrome and Internet Explorer start including native support for DANE, it will start to gain momentum, which will in turn drive DNSSEC adoption. It would be great to see DANE gain widespread adoption as I believe it could go a long way to making the Internet a safer, more secure place.
Unfortunately, there is a huge business that revolves around issuing and validating X.509 certificates and DANE could jeopardise that revenue stream, which ultimately may prove to be the main reason why it doesn’t take off.
About Paul Roberts
