What is DANE?

DANE (DNS-based Authentication of Named Entities) is the option to use secured DNS infrastructure to store generic verifiable information for multi-factor verification. The most common use of DANE today is the TLSA record type (Transport Layer Security Authentication), which allows users to verify the PKIX certificate received from a website by querying for its information in DNS. TLSA is specified in RFC 6698.

Why Use DANE?

For decades now, we have attempted to secure the Internet by associating cryptographic keys with names, and call them “certificates.” Then we have several entities known as Certificate Authorities (CAs) that we pay to issue and to maintain the integrity of these certificates. This public CA module is fundamentally flawed because the typical list of trusted CA’s in a web browser number in several dozens, and they range from DigiCert, VeriSign, to the lesser known Tubitak (Turkish Government) and HongKong Post Office.

A single trusted CA can undermine the security of the entire system, because, by design, any CA can issue certificates for any domain name, such as www.infoblox.com, and that particular illegitimate certificate would not raise warnings on the billions of web browsers. Over the past few years, we have seen malicious and deliberate attempts by attackers or governments to forge certificates for well-known domain names such as google.com or microsoft.com, in an attempt to wiretap or subvert TLS-protected websites.

Another common technique uses the man-in-the-middle style attack to intercept the user’s connection handshake with an intermediate device. This is common in many corporate environments where a web proxy intercepts the user’s secure web connection in order to analyze the encrypted traffic, but this can also be employed by an attacker for snooping.

DANE offers the option for clients to seek a second source of verification, in the case of TLSA, certificate information. Leveraging the authentication inherently in DNSSEC, organizations can publish the legitimate TLS certificate information in DNS, allowing clients to verify that the certificate information published over HTTPS matches the one published over DNS.

How Does DANE/TLSA Work?

Figure FAQ-2 below illustrates the simplified steps of clients using DANE to verify a website’s certificate information.

Figure FAQ-2:

• The client browser connects to https://www.example.com
• The web server replies with its certificate
• The client asks its local DNS server for the TLSA record of www.example.com
• The DNS server performs a normal DNS lookup for www.example.com TLSA record, uses DNSSEC to validate the response that came from the example.com authoritative name servers

After receiving the validated TLSA record, the client browser computes and compares the value of the TLSA record from DNS with the certificate received from web server. If the two do not match, the web browser displays a warning and does not load the page.

What is in the TLSA record?

Figure FAQ-3 shows an example of a TLSA record for the domain www.example.com:

In this example, the administrators of example.com took the certificate it published for the website, and generated a SHA-256 hash of the certificate, and published the hash as a TLSA resource record in DNS. This can be done using open source tools such as OpenSSL, or free online tools such as Shumon Huque’s page: https://www.huque.com/bin/gen_tlsa.

Once published, supported clients (browsers) will seek out this record after it has received a copy of the website’s certificate, and run its own computation to ensure that the information received over HTTPS matches the information received over DNSSEC.

TLSA is not limited to only verifying website identities, it can also be used to verify other services such as mail. Figure FAQ-4 shows an example of a TLSA record that provides information about an IMAP server:

The same principle applies here, if the user is using supported email software when it connects to the IMAP server, it double checks the identity of the IMAP server received over port 993 against the information it received over DNSSEC on port 53. If the two do not match, the email client does not proceed to send the email.

Dependencies for DANE

Although it is not a strict technical dependency, it goes without saying that one cannot have DANE without having DNSSEC. Publishing all of this verification information for security purposes is a waste of time if the publishing mechanism itself (DNS) is not secured. Without DNSSEC, an attacker who spoofed the web site’s certificate could just as easily spoof the TLSA record, rendering this second layer of checking useless.

Another dependency for DANE that is currently lacking is client support. While no major browsers have DANE/TLSA support built-in natively yet, many will support it through plugin or extension; same for other software such as email.