You may be familiar with the benefits of using DNSSEC to provide authentication and integrity for your DNS information. DNSSEC is a lot like dental floss: we all know that it is good for our health, but few enterprise organizations actually put forth the effort to implement the best practice. If organizations do not use DNSSEC then they are susceptible to a variety of DNS-based attacks. Attackers could falsify DNS responses or attempt a DNS cache poisoning attack. The good news is that now that the large Top Level Domains (TLDs) have been signed, more and more organizations are deploying DNSSEC.
You may also be aware of how Certificate Authorities (CAs) issue digital certificates that can be used to secure web communications using Transport-Layer Security (TLS) (formerly Secure Sockets Layer (SSL)). If an organization does not use X.509 certificates issued by Certificate Authorities with TLS to protect their applications, then any of their TCP-based communications are subject to eavesdropping or hijacking. There could also be errant self-signed SSL certificates lurking about along with mobile apps and other software that do not check for the validity of the certificate. The good news is that, due to the most recent revelations about government eavesdropping on communications, more organizations have a desire to use HTTPS instead of less-secure unencrypted HTTP web services.
These two methods of DNSSEC and TLS provide two forms of validating the authenticity of a domain name or a web site. However, they use two different methods of validating the service. DNSSEC provides a method to digitally sign the DNS records and authenticate the entries via a chain of trust that starts with the root zone. CAs provide an independent third party verification that the named subject of the certificate is valid thus creating a Public Key Infrastructure (PKI) system. When a CA issues an X.509 certificate to a web service, the key is used to aid in the negotiation of a TLS session key to encrypt the web page contents.
Problems with These Two Systems
The problem that has existed for many years is that these two methods of providing authenticity for a domain-name or a Fully-Qualified Domain-Name (FQDN) for a web site have not been tied together. The DNSSEC and the CA/TLS chain of trust have been independent and are not linked together.
The TLS certificate does not confirm that the organization running the web server officially owns that domain-name. Also, the DNS information for the FQDN does not have information about which CA is preferred by this organization. The security of the certificate is only as strong as the weakest of the 60-to-100 trusted CAs pre-loaded into the web browser. This has led to security issues related to either the DNS database information or CA issuer being compromised. Examples of this include the March 11th Comodo security incident and the DigiNotar SSL Certificate security breach in the summer of 2011. These incidents lead to the generation of false certificates.
Therefore, relying solely on the security of DNSSEC or the security of a certificate is not the ideal practice. History has taught us that the most secure systems are those that use a combination of “diversity of defense” and “defense in depth.”
DNS-based Authentication of Named Entities (DANE)
The idea behind DANE (DNS-based Authentication of Named Entities) is that it provides a way to cross-verify the domain-name information and the CA-issued certificate being used. DNSSEC provides authenticity of the named-entity (the domain-name and the FQDN of the web server) and has a digest of the CA’s certificate that it prefers clients use to validate its CA-issued certificate. The client can then check that the CA vouches for the authenticity of the named-entity and that the FQDN within the certificate matches the web site the client wants to visit. This cross-linking of the authenticated information in DNS and the certificate provides an additional dimension of validation and thus security.
This can be likened to the two-factor authentication systems that we are familiar with. Multi-factor authentication systems could use a token (something you have) and a pin (something you know) or a finger print, palm scan, or retinal scan (something you are). In the case of DANE, the two-factors are a DNSSEC authenticated authoritative DNS entry about the valid certificate and an actual certificate that can be validated by a trusted CA.
The Internet Engineering Task Force (IETF) created a DANE working group back in 2011. Since then, the group has created two critical RFCs that define the DANE method.
- RFC 6394 – Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
- RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
The first RFC 6394 covers the motivation for DANE similar to what we have just described. The second RFC 6698 describes a new DNS resource record (TLSA) that is used to convey the information about the certificate or certificate authority used for that DNS name.
The way DANE works starts with the first DNS query from the client’s resolver. The validation of the DNS information utilizes DNSSEC to authenticate that the queried DNS server is authoritative for answering the query. The client’s resolver checks the chain of trust and the integrity of the response. The client’s browser then proceeds to establish a connection to the web server running at the IP address returned by DNS. That web server will complete the 3-way handshake and then start to establish the HTTPS connection. But first the client will validate the certificate being provided by the web service with the CA and also check that the DANE TLSA entry matches the certificate. If the DNS and certificate information are all in order, authenticated by their chain of trust, and haven’t been modified, then the HTTPS connection proceeds.
There are many useful resources on DANE that you can read to gain a deeper understanding. The Internet Society (ISOC) has been advocating the use of DNSSEC and is also providing information on the use of DANE. Dan York has been busy speaking publically about the benefits of DNSSEC and DANE and has shared much of his information. Richard Barnes also wrote a nice paper titled “DANE: Taking TLS Authentication to the Next Level Using DNSSEC,” which was published in the IETF journal in October 2011.
Verisign has also been communicating about the benefits of using DNSSEC and DANE. Their document “Reducing the X.509 Attack Surface with DNSSEC’s DANE” is a great resource. This same information was also published in an academic journal on Securing and Trusting Internet Names (SATIN) 2012.
The Internet Protocol Journal, sadly not in publication anymore, had two great complementary articles on DANE and TLS security in, Volume 15, No. 1.
- Domain Name Authentication with DNSSEC and DANE, by Richard L. Barnes, BBN Technologies
- Hacking Away at Internet Security, by Geoff Huston, APNIC
Creating Your TLSA Record
In order to configure DANE an organization simply needs to put the information about their preferred CA into their DNS information. The client’s browser will check this to validate that the proper certificate is being used based on the URL that the user entered into the browser. The browser will check the issuer of the certificate with the CA that DNS says should be used for that FQDN. This is done by creating a new TLS Trust Anchors (TLSA) resource record in the DNS zone file for the particular FQDN. This TLSA record must be signed with DNSSEC. For example, a TLSA record for the FQDN www.example.com would be a record with the name 443.tcp.www.example.com.
To get DANE to work you need to have DNSSEC configured on your authoritative DNS server. Once that step is complete, you can create the TLSA resource record (RR). The TLSA record will contain three numbers, one for the “certificate usage” (0 to 3) to indicate the type of certificate, the “selector field” (0 or 1), and the “matching type” (0 to 2) for the type of hash used. A CA certificate public key with a full certificate using type 1 SHA-256 hash entry in a BIND 9.8.3+ zone file would look something like the following:
_443._tcp.www.example.com. IN TLSA ( 0 0 1 91751cee0a1ab8414400238a761411daa29643ab4b8243e9a91649e25be53ada )
Section 2 of RFC 6698 gives you information on how to create these TLS entries.
The good news is that TLSA resource records are not tied to either IPv4 or IPv6 addresses. Therefore, the same DANE information can be used regardless of the IP version being used for the transport between client and server.
Certification Authority Authorization (CAA)
The IETF has also worked on a parallel effort to use a DNS entry to point to the CA that will be used to issue certificates for the domain name. The RFC that defines this standard is RFC 6844 – DNS Certification Authority Authorization (CAA) Resource Record.
This proposal sounds very similar to DANE, in that it provides some linkage between CAs and DNS information for a domain. However, this CAA record defines information that the certificate issuer (CA) can use to validate that they are authorized to create certificates for this domain ahead of when the certificate is actually created. The CA will perform the query for the CAA entry in DNS before they issue a certificate for that domain. As for DANE, the TLSA resource record is created after the CA has issued the certificate for the FQDN.
Use of CAA records does not require the use of DNSSEC, but the use of DNSSEC is always considered a best practice.
As an example: a CAA DNS resource record could indicate that the certificates for certs.example.com are issued by the CA example.net.
certs.example.com CAA 0 issue "example.net"
DANE Support in Browsers
For DANE to be effective, it needs to be implemented on the server-side in the DNSSEC deployment. It also needs to be implemented in the client-side software to verify the DNSSEC information, get the TLSA resource record, get the certificate, and then check that the certificate and the TLSA match. This means that DANE will need to be supported in the web browser.
There is a “DNSSEC/TLSA Validator” Firefox plugin called hash-slinger for Firefox on Linux, and a DANE Patrol add-on for Firefox.
There is conflicting information about whether DANE is supported in Google Chrome. This MozillaWiki page talks about DANE, thus giving indication that it is a “work in progress”.
There is also a SURFnet open source implementation of DANE called Danish.
The Internet Society (ISOC) Deploy360 program provides a list of web sites that use DANE. These “21 Sites You Can Use To Test DANE Support (DNSSEC + SSL/TLS)” can be used to test your browser.
Verisign Labs also provides a web page that you can browse to and validate that your web browser software supports DANE.
There are some concerns and challenges for DANE. If web browsers fail to check the DNSSEC and TLSA record information against the certificate/CA information then DANE is not being used. Also, the browser now has more steps to go through prior to delivering information and this could potentially slow down the connection. This is especially true if a content provider has a faulty DNSSEC implementation.
DANE Secures Many Services
A system like DANE is not only useful for securing web browsing. It could be used anywhere that TLS certificates are used and we want to check the authenticity of the DNS information. DANE can be used with TCP applications and could also protect Datagram Transport Layer Security (DTLS) for securing UDP flows. The list of applications and services that would benefit from DANE also includes:
- E-mail using S/MIME (e.g. Postfix)
- SSL-Based VPNs
- VoIP systems (e.g. SIPS, SIP-TLS)
- Jabber/XMPP interactions for the Internet of Things (IoT)
- SDN controllers communicating southbound with network devices (e.g. Cisco’s OnePK, OpenFlow, and others)
The challenge here is that many of these applications will need to be modified, just like web browsers, to look for the DANE information and correlate it with the certification information.
We hope that in the near future DANE is embraced by more organizations. Once DANE is incorporated into more software systems the Internet will become a safer, more secure place.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/blogs/2014/04/14/dns-based-authentication-named-entities-dane.
