DANE is a proposed standard that has the potential to make widespread email encryption a reality (today, most emails are transmitted unencrypted). It does not only provide a trust scheme (like the certificate authority system) using DNSSEC, but also the means to know if a domain supports encrypted email transfer. The Halon platform supports DANE since 3.4-rocky-r2.
How DANE works
DANE is only available over DNSSEC, and uses the TLSA record type. An email server (MTA) only needs to make one extra DNS query to use DANE, namely
$ host -tmx freebsd.org freebsd.org mail is handled by 10 mx1.freebsd.org. $ host -ttlsa _25._tcp.mx1.freebsd.org _25._tcp.mx1.freebsd.org has TLSA record 3 0 1 2B73BB905F1...
and the server's certificate is compared against the DNS record. The output (logs) from a Halon system with and without DANE look like
smtp_lookup_rcpt(["host" => "lookup-mx", "tls"=>"dane"], "", "[email protected]"); // DANE
smtp_lookup_rcpt(["host" => "lookup-mx", "tls"=>"dane"], "", "[email protected]"); // Insecure
Connecting to [2001:1900:2254:206a::19:1]:25 (DNSSEC) X.509: /OU=Domain Control Validated/OU=Gandi Standard... DANE: validated successfully Connection is now using TLS ...
Connecting to [2a00:1450:4010:c06::1b]:25 DANE: insecure name gmail.com (falling back to optional TLS) X.509: /C=US/ST=California/L=Mountain View/O=Google Inc... X.509 error: unable to get local issuer certificate (20) Connection is now using TLS ...
How to use DANE
It's fairly simple to start using DANE, and we encourage you to at least start sending email with (verifying) DANE right away.
To enable DANE verification in the Halon SMTP server, simply change the TLS mode to dane. It can be changed for the outbound (typically lookup-mx) transport profile, or using the SetTLS() function. We recommend that you enable the built-in DNS cache (with DNSSEC enabled) instead of relying on an external DNS server's AD-bit.
In order to allow others to send DANE verified email to your server, you domain needs to be DNSSEC signed. In theory, it's no more difficult than publishing your SMTP servers' certificate signatures as TLSA records in your DNS using the same name as the MX points at, but prefixed with _25._tcp. As usual, everything's a bit more complicated in practice. The full certificate fingerprint (used with 3 0 1) can be extracted with
openssl x509 -noout -fingerprint -sha256 < path-to-cert | tr -d :
or you can simply use Huque's TLSA generator. The result should look like:
mx1.freebsd.org. IN A 220.127.116.11 _25._tcp.mx1.freebsd.org. IN TLSA 3 0 1 2B73BB905F...
Halon's DANE implementation is based on the NLnet Labs ldns library's DANE functions (which are included in FreeBSD). Outbound SMTP connections are handled by the libh_smtp++ library, which is used by both HSL core functions such as smtp_lookup_rcpt() as well as the mailqueued process and its corresponding pre-delivery context.
DANE is proposed in RFC 6698 by Hoffman and Schlyter as an alternative to CAs. The CA system has been subject to criticism during the last years, following compromise and mishaps of several major CAs. To make things worse, the revocation systems doesn't work very well in practice. DANE builds on DNSSEC which provides a hierarchal scheme (the root, TLDs, domains and so on), as opposed to the flat CA system where any trusted CA can issue a certificate in the name of anyone.
As always, there are arguments for and against. While a hierarchal system sure is preferable, the transfer of control and responsibility to the DNS system's owners (governments, DNS admins) is a topic much discussion. There's also work to improve the CA system with supplementary techniques such as key pinning and added perspective. Nevertheless, DANE stands strong to improve the security in many areas, such as email.
Postfix was probably the first email server to support RFC 7672 (DANE for SMTP), and Exim support is underway. The fact that those two are the most widely used SMTP servers, and the somewhat strong DNSSEC adoption, is a solid foundation for DANE.