DNS-Based Authentication of Named Entities or DANE is a new way of associating a certificate to a domain name without having to rely on external third parties. Published under RFC 7671, it introduces a new Internet standard for setting up TLS (Transport Layer Security) communication between a client and a server, without having to rely on trusted Certificate Authorities (CAs).

The traditional CA model, upon which TLS has depended so far, has the inherent problem of “too many CAs” which allows any of these CAs to issue a certificate for any domain. Instead, DANE relies on the DNSSEC infrastructure (Domain Name System Security Extensions) to bind a domain name to a certificate.

Why was DANE developed?

There are two main reasons:

  • Improper use of trusted third-party CAs - Attackers can sometimes successfully impersonate a person or service and obtain a rogue certificate. Although this certificate is valid and issued by a trusted third party, it is not designated to the intended person. Other mis-issuance of certificates can be found here.
  • Eliminating the possibility of MITM (Man-In-The-Middle) attacks - MITM is when an attacker intercepts the conversation between a client and server by inserting themselves into the middle of the conversation, tricking both parties to think that they are talking to each other. This can lead to TLS session downgrade or cache poisoning. Often, when a client tries to connect to a server, the server has no way of knowing in advance that the server on the other side supports TLS or that it is talking to the correct server.

What is needed to deploy DANE?

  • Security-aware resolver that can query and validate DNSSEC and TLSA records
  • DNSSEC signed zone and RRsets

Can DANE be used by any application?

As long as the application uses TLS to connect to services identified by domain names, DANE is universal. It is backwards compatible, so if DANE is not supported by a mail server, the client can fall back to using STARTTLS or even clear text. It was developed to be deployed gradually while interoperating with the existing email backbone. As DANE adoption grows, it will promote the use of DNSSEC and vice versa. We will have a look at the adoption rate of DANE a bit later. 

So, can it be used to secure email?

Yes, as hinted in the previous section, one of the main applications that can make use of DANE is, indeed, email.

Existing protocols are not sufficient to protect your email from being intercepted along the way or from landing in the wrong hands. 

DANE is, in fact, the only protocol so far that can protect your email by enabling your client to know in advance, whether or not the server on the other side supports TLS, that the data it receives is coming from an authenticated server, and hasn't been modified in transit. If a malicious party tries to intercept the traffic or modify it in transit, DANE will detect that, abort the connection and either try another server or delay the message until a secure channel can be established.

How does DANE achieve the above?

DANE makes use of the already existing DNSSEC protocol, to make sure the data it receives is authentic and has not been tampered with. DANE also introduces a new DNS RR type called TLSA which helps to signal to the client that a server supports TLS. 

A TLSA record needs to be set up for each application that makes use of TLS. Each one of those applications will run on different ports and based on the port number, a TLSA record can exist. 

Here is an example of a left-most label of a TLSA record for an SMTP service running TLS, for the domain “example.com”: "_25._tcp.mail.example.com"

To retrieve the TLSA record, a client would construct a DNS query that would look like this:  "_25._tcp.mail.example.com". 

To request a TLSA resource record for a HTTP server running TLS on port 443 at "www.example.com", the query would look like this: "_443._tcp.www.example.com".

But I thought that DMARC protects my email, why do I need DANE now?

Both technologies can be easily confused and while both DANE and DMARC involve some form of authentication, they are fundamentally different and protect different parts of the communication. 

DMARC authenticates the sending FROM domain and prevents it from being spoofed so that a recipient can be sure the email has come from the rightful owner of the domain. You can find out more information about DMARC here.

DANE on the other hand provides a secure channel between the sender and recipient, ensuring that the sender is talking to the right recipient while preventing MITM from intercepting or modifying the email in transit.  

Although both technologies complement each other, they are not a replacement for one another.

What is the adoption rate of DANE?

The adoption of DANE and DNSSEC, as one of the prerequisites for DANE, seems to have grown considerably over the last few years, with some areas reporting an increase in adoption of up to 300%.

What are some of the recommended protocols to implement for more secure email communication?

Sending and receiving email does not just involve the use of POP, IMAP or SMTP, it heavily relies on the DNS infrastructure. Inherently, all of those technologies are insecure and require other protocols to be involved in order to secure different parts of the communication. 

The main protocols to implement on your domain / mail server are:

  1. SPF, DKIM, DMARC - to prevent your domain from being used in spoofing attacks against your clients/partners. 
  2. DNSSEC - to protect yourself from DNS cache poisoning, and to make sure that the answers you get from DNS are valid and authentic.
  3. DANE - to protect your client-server communication with TLS and prevent MITM attacks.

By configuring the above protocols, you will not only protect yourself and your clients but also contribute towards a safer online email environment.

If you'd like to educate yourself further about DANE or test your current configuration, take a look at our further reading sources below:

For more information about security protocols and email configuration, feel free to get in touch.