Will DANE for SMTP solve all of your GDPR problems?

The short answer: probably not. The long answer: keep reading.

What is DANE?

According to Wikipedia:

DNS-based Authentication of Named Entities (DANE) is a protocol to allow X.509 certificates, commonly used for Transport Layer Security (TLS), to be bound to DNS names using Domain Name System Security Extensions (DNSSEC)

In less technical terms, DANE is a protocol which allows you to securely associate a domain name with an X.509 certificate.

To support DANE, the following key ingredients are required:

The client (for example a web browser or SMTP client) and server must support DNSSEC.
Client and server must support the DANE protocol.
Server certificate must be stored in DNS and the DNS record must be signed.

DANE has many sub-protocols, like for example DANE for SMTP, DANE for OpenPGP etc. For this article we will only focus on DANE for SMTP.

One of the reasons DANE for SMTP has been introduced is to fix a number of security flaws with TLS and SMTP. A problem with TLS and SMTP is that there is no direct relationship between a recipients domain and the authoritative SMTP server for that domain. The authoritative SMTP servers for a domain are stored in DNS MX records. In most cases, the domain names for the listed authoritative SMTP servers are different from the recipients' domain.

Example

The official domain name for the Dutch government is overheid.nl. However, the DNS MX records for the overheid.nl domain point to servers from another domain:

overheid.nl.        300 IN  MX  20 mx01-koop.solvinity.com.
overheid.nl.        300 IN  MX  20 mx02-koop.solvinity.com.

Because the domain overheid.nl does not match the domain solvinity.com it's impossible to know for certain that the servers mx01-koop.solvinity.com and mx02-koop.solvinity.com are the correct authoritative SMTP servers for overheid.nl. We can only rely on the DNS server to give us the correct results. DNS however is not secure by default and the DNS results should therefore not be trusted unless DNSSEC is used.

Another problem DANE tries to solve is the "Too Many Certification Authorities" problem. In order to trust a server certificate, the client should trust the issuer of that certificate and therefore has to trust a large list of certificate authorities (CAs). DANE tries to remove the CA from the equation by storing the X.509 certificate into DNS and no longer rely on CAs.

Issues with DANE

The problem with DANE is that DNSSEC is required. DNSSEC is however still not widely deployed. Big players like Microsoft (Office 365)¹ and Gmail² at the moment do not support DNSSEC.

DANE requires that DNSSEC is supported by sender and recipient. Setting up DNSSEC is not easy and error prone.

While I think the "Too Many Certification Authorities" problem is certainly a problem, replacing many CAs by basically just one CA may not be the solution to all problems.

A more serious problem with DANE is that it's often presented as the solution to email encryption. DANE is a protocol to make a TLS connection less vulnerable to a "Man in The Middle attack". However, it does not provide stronger security than what is provided by TLS. TLS only encrypts the connection. The individual messages are not encrypted. The sender can only be certain that the connection to the first SMTP server is encrypted and secured with DANE. What happens next, is no longer under control of the sender. When the email reaches the users Inbox, the message may have been copied and stored in plain text multiple times or even altered without detection.

Combine DANE with message encryption

While DANE improves the security of TLS, DANE by itself may not be sufficient to fully protect your email. The best option is to use DANE for protecting the channel and S/MIME for protecting the message by encryption and signing.