DANE (DNS-based Authentication of Named Entities) is a new Internet security protocol (RFC6698). It allows publishing parts of a server’s TLS Certificate in DNS, utilizing DNSSEC to prevent forgery of that important information.
- 31% of TLDs are signed and accepting signed registrations under 31% of tlds.
- 20% of BT DNSSEC survey respondents are in the process of deploying DNSSEC to recursive servers (other studies showed that about 6-8% of recursives are validating DNSSEC already).
- The number of signed domains in .com and .net has surpassed the 150,000 mark under number of signed domains.
What is it?
When you log into your bank’s website, a little lock appears in your browser’s address bar. This is because the connection is secured, generally using Transport Layer Security or TLS. A TLS connection between two computers — like a client and a server — is established by exchanging certain data necessary to start the secure transmission.
Part of that exchange is the server’s digital certificate. The ‘client’ could not trust just any certificate though; it has a list of certificates from trusted companies or “Certificate Authorities” (CA) who issue them. Once the ‘client’ receives the certificate, it finds out who signed the certificate, checks the certificate of an issuer and gradually works its way back to one of the trusted CA certificates it knows. This is the “chain of trust“.
Unfortunately, the number of “trusted CA’s” that has to be shipped with each client has grown from about 50 in 2008 to 359 today. There are 60+ organizations that are allowed to sign digital certificates. Many of them have tens to hundreds of resellers who are allowed to do the signing.
In total, there are more than 1500 commercial entities who may start the process of issuing a TLS certificate for a given website name.
The problem with imposters
Given 1500 possible entities, it seems probable that it’s only a matter of time before an imposter will be granted a certificate and clients treat the imposter as legitimate. In other words, if one of the 1500 messes up, it’s possible that you will connect with some phony site and think it to be your bank, even when you carefully check for the little lock icon.
We have already seen examples of wrong signings over the course of the last three years. DigiNortar is probably the most discussed, but there were others and there could be those that were spotted before they got to the news. While we were preparing this article, another one happened.
Those concerns are part of what motivated the participants in the IETF (Internet Engineering Task Force) DANE working group. The result of 10 months worth of work is a protocol that allows administrators to limit server authentication to a particular trusted CA or to even replace the CA system altogether.
This is done by adding a DNS resource record (TLSA) that a connecting client checks as part of setting up the TLS connection.
Since the connection already depends on the DNS, this approach is exactly as safe as the connection ever was. Since the data is protected by DNSSEC, it isn’t subject to forgery attacks.
If you read the RFC and reviews of DANE, you’ll quickly come to same conclusion as I did: “Yeah, great. But how do we get to use this without waiting for the whole world to switch?” You probably know the answer…we should start using it now.
To the engineers out there who are striving to make the Internet a better place, it’s time to do the following:
Start evaluating and rolling out DNSSEC
We can do it for you. DNSSEC is included with any level of DynECT Managed DNS, but the time has come when DIY is safe enough and there are plenty of tools and online instructions that can help you.
Help to increase DNSSEC and DANE support in libraries and applications and learn more along the way
Projects like ldns and dnspython are supporting TLSA records and both have good programming abstracts for DNSSEC primitives. It would be great to see this happening in other DNS libraries and accelerate adoption of those primitives in higher level libs, simplifying the usage of DANE in applications.
Be serious about security
In modern systems, we use a number of little APIs which send data without encryption or use self-signed certificates. Most people would use similar approaches for securing SMTP and database communication. Stop doing it. Secure your communication with TLS and start adding DANE checks to your applications!
Also, be conscious about things that DANE does not solve in the X.509 world. Do not email certificates as you would not email your passwords. Use providers who do not let you to reset passwords from your account using email. Rely on higher quality passwords to access your accounts in certificate authority Web sites.
Follow Internet Society Deploy 360 Programme
It is a great collection of DANE news, tools and ideas.
Together, we may shorten the time that is required to improve Internet security. In doing so, we can make it possible to add DANE in more client programs, and drive awareness of the consumers about current trust problems with that infamous lock icon.
(Thanks to Andrew Sullivan and Carl Levine for their help in preparing this post.)