909-744-2891

2016-12-12 DANE - the killer app for DNSSEC

DANE - the killer app for DNSSEC

For those not familiar with DANE, read this first. That was written before RFC6698 or the updated RFC7671 and RFC7672 were published, but it is still an excellent introduction to DANE. The following presentations at ICANN 53, the Internet Society Deploy 360 program and others are worth reading.

I started signing zones with DNSSEC in July 2008, placing the DS records in the ISC DLV. The root zone was signed in July 2010. I moved my domain registrations to gkg.net in November 2012 since my old registrar had no mechanism to get my DS records into the various tlds. RFC6698 describing DANE was published in August 2012. I started publishing DANE records in December 2012.

Why do we need DANE? Because the X.509 certificate trust model is totally broken, and because it really only handles web certificates or other uses where there is a human in the loop. X.509 certificates are almost useless for securing things like SMTP, where both ends are simply processes running in different machines.

Consider the case where there is a human in the loop - typically using a browser talking to a web server. The browser (or client machine operating system) does some DNS lookups, and gets the IP address of web server. It talks to the web server and gets an X.509 certificate. It then trusts that certificate if it was signed by any one of about 2000 certificate authorities. That is the fatal weakness in the current trust model.

The browsers place too much trust in those certificate authorities. Any of those CAs can sign a certificate for any domain name. China (CNNIC) signed a CA certificate (delegating signature authority) for Cairo-based MCS Holdings which in turn signed an unauthorized certificate for Google. Google responded by removing the CNNIC certificate from Chrome - one down and only a few thousand more to go.

DANE solves this problem - the domain owner can constrain the set of CAs that can sign the domain owners X.509 certificates. But with DANE, there is no need to stop there. The domain owner can constrain the acceptable X.509 certificates to a single specific certificate, even one generated and self-signed by the domain owner. So there is then no need for the CA at all.

DANE solves two problems - distrusting a certificate that would normally be trusted (with a TLSA record that does not match the certificate supplied by the server), and trusting a certificate that would not normally be trusted (with a TLSA record matching the self-signed certificate supplied by the server). The availability of free certificates from https://letsencrypt.org/ makes the second case less important, but still useful.

TLS DNSSEC chain extension is another attempt at increasing security, but it really only addresses the second case (trusting a certificate that would not normally be trusted) by supplying the DNSSEC chain in the TLS handshake. It does nothing to reduce the major threat - unauthorized certificates signed by a corrupted but trusted CA.

Certificate pinning is an attempt to reduce that threat. See this for a primer on pinning, and this or RFC7469 for pinning HTTP certificates. Of course, that is specific to HTTP, and does not generalize to other protocols. It has no out-of-band confirmation mechanism similar to the SSH "do you want to trust this key" question. Instead, it simply assumes that the first connection supplies the proper key. If you do any sort of regular key rotation, you need to consider the max-age parameter and pre-publish the hash of the next key that you will use.