Adventures in DANE

This post will reflect on the relatively new DNS-based Authentication of Named Entities(DANE) protocol from the Internet Engineering Task Force(IETF). We will first explain how DANE works, talk about what DANE can and cannot do, then briefly discuss the future of Internet encryption standards in general before wrapping up.

What are DNSSEC and DANE?

DANE is defined in RFC 6698 and further clarified in RFC 7218. DANE depends entirely on DNSSEC, which is older and considerably more complicated. For our purposes, the only thing the reader need know about DNSSEC is that it solves the problem of trusting DNS responses. Simply put, DNSSEC ensures that DNS requests return responses that are cryptographically assured.

DANE builds on this assurance by hosting hashes of cryptographic keys in DNS. DNSSEC assures that what we see in DNS is exactly as it should be, DANE then exploits this assurance by providing a secondary trust network for cryptographic key verification. This secondary trust network is the DNS hierarchy.

Let's look at an example. I have configured the test domain https://synonomic.com/ for HTTPS, TLS, DNSSEC and DANE. Let's examine what this means.

If you visit https://synonomic.com/ with a modern web browser it will probably complain that it is untrusted, before asking you create an exception. This is because synonymic.com's TLS certificate is not signed by any of the Certificate Authorities(CA) that your browser trusts. In setting up synonymic.com I created my own self signed certificate, and didn't bother to get it signed by a CA.¹

Instead, I enabled DNSSEC for synonymic.com, then created a hash of my self signed certificate and stuck it in a DNS TLSA record. TLSA records are where DANE hosts cryptographic information for a given service. If your browser supported DANE, it would download the TLS certificate for synonymic.com, compute its hash, then compare that against what is hosted in synonymic.com's TLSA record. If the two hashes were the same it could trust the certificate presented by synonymic.com. If the two hashes were different then your browser would know something fishy was happening, and not trust the certificate presented by the web server at synonymic.com.

If you're on a UNIX system you can query the TLSA record for synonymic.com with the following command.

dig +multi _443._tcp.synonomic.com. TLSA

The answer should look something like this.

_443._tcp.synonomic.com. 21599 IN TLSA 3 0 2 (
                            D98DA7EE3816E8778CD41C619D868817EC2874CC3C80
                            D1CA25E7579465CDED2D6BD57CEB4C2D1943039EAB48
                            C6403619A83B0025C6CF807992C1196CB42EE386 )

Let's break this answer down.

The top line repeats the name of the record(_443._tcp.synonomic.com.) you queried. Since different services on a single host can use different certificates, TLSA records include the IP protocol(tcp) and port number(443) in the record. This is followed by three items generic to all DNS records, the TTL(21599), the scope of record(IN for Internet) and the name of the record type(TLSA).

After these we have four values specific to TLSA records. The certificate usage(3), the selector(0), the matching type(2), and finally the hash of synonymic.com's TLS certificate(D98DA..).

The certificate usage field(3) can contain a range from 0-3. By specifying 3 we're saying this record contains a hash of synonymic.com's TLS certificate. TLSA records can also be used to force a specific CA trust anchor. For example, if this value was 2 and the TLSA record contained the hash of CA StartSSL's signing certificate, a supporting browser would require that synonym.com's TLS certificate be signed by the StartSSL CA.

The selector field(0) can have a range of 0-1 and simply states which format of the certificate is to hashed. It's uninteresting for our discussion.

The matching type field(2) states which algorithm is used to compute the hash.²

Finally we have the actual hash(D98DA..) of the TLS certificate.

What can DANE do?

DANE provides a secondary chain of trust for TLS certificates. It enables TLS clients to compare the certificate presented to them by the server, to what is hosted in DNS. This prevents common Man In The Middle(MITM) attacks where an attacker intercepts a connection prior to it being established, presents its own certificate to both ends, and then sits in between the victim end-points capturing and decrypting everything. DANE prevents this common MITM attack in the same way our current CA system does, by providing a secondary means of verifying the server's presented certificate.

The problem with CAs is that they get subverted³, and since our browsers implicitly trust all of them equally, a single subverted CA means every site using HTTPS is theoretically vulnerable. For example, if the operator of www.example.com purchases a certificate from CA-X, and criminals break into CA-Y, a MITM attack could still succeed against visitors to www.example.com. TLS clients cannot know from which CA an operator has purchased their certificate. Thus an attacker could present a bad certificate to clients visiting www.example.com signed by CA-Y, and the clients would accept it as valid.

DANE has two answers to this type of attack. First, since a hash of the correct certificate is hosted in DNS, clients can compare the certificate presented by the server to what is hosted in DNS. Then only proceed if they match. Secondly, DANE can lock a given DNS host to work with certificates issued by only one CA. So referencing the above example, if CA-Y is penetrated it won't matter, because DANE compliant clients visiting www.example.com will know that only certificates issued by CA-X are valid for www.example.com.

What can DANE not do?

DANE cannot link a given service to a real world identity. For example, DANE cannot tell you that synonymic.com is the website of Andrew McConachie. Take a closer look at the certificate for synonymic.com. It's issued to, and issued by, "Fake". DANE don't care. DANE only ensures that the TLS certificate presented by the web server at synonymic.com matches the hash in DNS. This won't stop phishing attacks where a person is tricked into going to the wrong website, since that website's TLS certificate would still match the hash in the TLSA record.

The way website operators tie identity to TLS certificates today is by getting special Extended Validation(EV) certificates from CAs. When a website owner requests an EV certificate from a CA that CA goes through a more extensive identification process. The purpose of which is to directly link the DNS name to a real world organization or individual. This is generally a rather thorough examination, and as such is more expensive than getting a normal certificate. EV certificates are also generally considered more secure than DV certificates, at least for HTTPS. If a website has an EV certificate, web browsers will display the name of the organization in the address bar.

Normal, or Domain Validated(DV), certificates make no claims regarding real world identity. If you control a DNS name you can get a DV certificate for that name. In this way DV certificates and DANE are very similar in the levels of trust they afford. They only differ in what infrastructure backs up this trust.

Does DANE play well with others?

DANE does not obviate the need for other trust mechanisms, in fact it was designed to play well with them. Unlike what some people think, the purpose of DANE is not to do away with the CA system. It is to provide another chain of trust based on the DNS hierarchy.

Certificate Transparency(CT) is another new standard from the IETF.⁴ It is standardized in RFC 6962. Simply put, CT establishes a public audit trail of issued TLS certificates that browsers and other clients can check against. As certificates are issued participating CSs add them to a write once audit trail. Certificates added to this audit trail cannot be removed or overwritten. TLS clients can then compare the certificate presented by a given website with what is in the audit trail. CT does not interfere with DANE, instead they complement one another. There is no reason today why a given site cannot be protected by our current CA system, DANE, and Certificate Transparency. The more the better. Redundancy and heterogeneity lead to more secure environments.⁵

The challenge moving forward for TLS clients will be in how these different models are used to determine trust, and presented to the user. Right now Firefox shows a lock and, if it's an EV certificate, the name of the organization in the address bar.⁶ This is all based on the CA system of trust. If DNSSEC/DANE, and Certificate Transparency all gain adoption browser manufacturers will have to rethink how trust information is presented to their users. This is not going to be easy. To some degree boiling down all of this complexity to a single trust decision for the end user will be necessary, and trade-offs of information presented vs. usability will be required.

Weak Adoption and the Future

DANE depends on DNSSEC to function, and DNSSEC adoption has been slow. However, in some ways DANE has been pushing DNSSEC adoption. This article has been focusing on using DANE for HTTPS, actually DANE has seen the most deployment success in email deployments.⁷ There has been significant uptake in DANE by email providers wishing to prevent so called Server In The Middle Attacks(SITM). This type of attack occurs when a rogue mail server sits between two mail servers and captures all mail traffic between them. DANE averts this type of attack by allowing both Simple Mail Transfer Protocol(SMTP) talkers to compare the presented certificate with what is in DNS. The IETF currently has an Internet Draft on using DANE and TLS to secure SMTP traffic.

I think we should expect adoption of DANE for email security to continue increasing before any significant adoption begins for HTTPS. Many technologies require some sort of 'killer app' that pushes their adoption, and I suspect many people see DANE as DNSSEC's killer app. I hope this is true, because one of the best ways we can thwart both pervasive monitoring by nation states, and illegal activities by criminals is increasing the adoption of TLS. Providing heterogeneous methods for assuring key integrity is also incredibly important. This article argued that a future with multiple methods for ensuring key integrity is preferable to a single winner. Our ideal secure Internet should have multiple independent means of verifying TLS certificates, DANE is just one of them.

Please contact me at andrewm AT ischool DOT berkeley DOT edu if you discover inaccuracies in this article.