The recent attack on the Comodo Certification Authority has not only shown how vulnerable the current public key infrastructure is, but also that the protocols (e.g., OSCP) used to mitigate these vulnerabilities once exploited, are not in use, not implemented correctly or not even implemented at all. Is this the beginning of the death of the PKI dragons and what alternatives do we have?

Several people have been looking at using DNS and DNSSEC to distribute and validate PKIX certificates, i.e. leveraging that fact that DNSSEC gives you an authenticated mechanism to distribute data from a domain name holder to any client on the Internet, and using this mechanism to bind public key material in a certificate to its associated domain name. Leif Johansson and myself wrote a draft on the subject back in 2002, but the IETF PKIX working group at that time was not really overwhelmed by our ideas. A lot of water has passed under the bridges since then, including an incipient universal deployment of DNSSEC. After the DNS root was signed last year, in combination with the current erosion of PKI security practices, the ideas was once again brought into daylight and a new IETF working group—DNS-based Authentication of Named Entities (DANE)—was formed.

The working group’s first draft describes how to use DNSSEC to associate certificates with domain names For TLS. In this context, a certificate association is a secure binding between a DNS name, TLS/DTLS transport protocol (i.e., TCP, UDP or SCTP) and port number, to an end entity’s certificate or to a certification authority’s certificate.

For a TLS server operator, this means that one can take a certificate issued by a certification authority (CA) and publish it in the DNS, telling the world what certificate(s) are to be expected for a given domain name, protocol and port. But is also means that one can—once widely deployed—publish a certificate you create by yourself, resulting in the same (if not better) security as we have today.

For a TLS client user, this means that when contacting a TLS server (e.g., a web server) one would look up any corresponding certificate associations in the DNS, validate the result using DNSSEC and—with very high confidence—verify that the certificate received from the TLS server actually belongs to the domain name.

The combination of DANE and the recent developments of HTTP Strict Transport Security and HASTLS, two protocols communicating TLS security policy, results in a very compelling set of protocols. Together with the current PKI model, or even standing by its own, DANE will change how we look at certificate validation. With DANE, the recent attacks on the dragons would no longer be possible and maybe—if the people still believe in dragons—they can both live together in perfect harmony in the valley of Internet security.