We have seen that STARTTLS leaves email servers open to man-in-the-middle attacks because of two shortcomings:
- It does not provide a way to know in advance whether the destination server supports TLS encryption;
- It does not provide a way to authenticate the destination server’s identity (hostname).
The second point could be addressed in a traditional manner with the use of certificates and certification authorities; email server owners could buy a certificate validating their server’s name, and mail transfer applications could verify the certificate whenever a TLS connection is established.
However, this method has several problems: it is relatively costly, which will stop many non-professional email server owners; it requires mail server applications to maintain and update a list of valid certification authorities and root certificates; it may require to know in advance, and list in the certificate, each and every domain for which the email server has to respond; and, more importantly, the cracking of a single certification authority would allow to produce and deploy valid (but forged) certificates for any domain name and email server in the world. Also, certificates alone would not solve the first issue in any way.
DNS-based Authentication of Named Entities (DANE) is a standard using DNS and DNSSEC to provide secure authentication for any Internet host, also including a mechanism to specify that a host supports, and actually requests, TLS-encrypted communication.
The standard (RFC 6698) was released in 2012, and only in 2015 its use for email transmission was formalized in RFC 7672; it is pretty new, and its deployment started only recently. However, it brings a substantial increase in security against email interception.
DANE allows domain name owners to use the DNS to publish a certificate association – that is, a statement that includes a certificate, or its hash, and associates it to a hostname.
Any client or originating server, when establishing an encrypted TLS connection with a destination server, can then look at the certificate that the destination server provides during the key agreement phase, and match it with the association published in the DNS for the server’s hostname. If the association matches, then the certificate proves that the destination server is actually identified by that hostname.
If the server’s domain name is not secured with DNSSEC, any attack forging DNS replies will fool DANE as well. DNSSEC provides a chain of trust similar to the one provided by a certification authority, but with one difference: there are hundreds of certification authorities and cracking one of them (or one of them going bad) is not that difficult, while the single DNS root set of keys is much easier to oversee and secure.
Also, as a standard policy, publishing a certificate association for an email server’s hostname implies that it requires STARTTLS and TLS encryption on all SMTP communications. If you find a certificate association for a destination server but the certificate does not match, you should assume that a man-in-the-middle attack is ongoing and stop all communications.
Certificate associations are published in special DNS records called TLSA records; different types of TLSA records are possible, with different meanings, depending on a specific field of the record named certificate usage.
For email security, the recommended TLSA record certificate usage value is 3 (DANE-EE); it means that the certificate included or hashed in the record will be used by the server to establish the TLS connection.
Another possibility is certificate usage 2 (DANE-TA); it means that the certificate included or hashed in the record will be used to sign, directly or indirectly, the certificate that will be used by the server to establish the TLS connection; in practice, TLSA records for usage 2 provide the root certificate of a certification authority or chain of trust that will vouch the actual server certificate.
As the DANE security check is deemed successful if even just one TLSA record for the hostname matches, publishing both certificate associations gives you some room for mistakes or glitches in the management of server certificates and keys.
Some care must be taken when changing the server keys/certificate; TLSA records, as any DNS record, take time to propagate through the network, so, if you change the certificate all of a sudden, even if you manage to immediately update your TLSA record on your authoritative name server, many clients will still see the old record and the verification will not match.
To solve this problem, the recommended procedure for DANE key rollover is to create the new keys and certificate without deploying them, to publish the new TLSA record together with the old one, to allow for ample propagation time to pass, and only then to deploy the new certificate in place of the old one and to remove the old TLSA record.
Another option to make your life easier is to publish only a hash of your public key, rather than of the entire certificate, and to rollover only the certificate by creating/requesting a new one using the same key used for the previous one; you should still rollover the keys every now and then with the aforementioned procedure, but you may do that less frequently. The selector field of the TLSA record allows you to specify whether you are publishing (a hash of) your full certificate (selector = 0), or just your public key (selector = 1); this latter option allows you to change the certificate without changing the TLSA record, as long as the key used for certificate generation stays the same.
A third field of the TLSA record, the matching type, specifies whether the record contains the full certificate or key, or just a hash of it, and in this case specifies the hashing algorithm; using some hashing is recommended.
This is why you will often see people identify the different types of TLSA records by the triplet of their field values; for example, a “3 0 1” TLSA record is a record for usage 3, publishing the full certificate (selector = 0) in SHA-256 hashed form (matching type = 1).
