Home / Blogs

Death of the PKI Dragons?

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.

By Jakob Schlyter, IT Security Advisor

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byDNIB.com


Sponsored byVerisign