Safe Transport

Identification Criteria

The problem here is with the criteria used to identify the counterpart. Anyone who pays attention only to the hostname mapped in the certificate's CN can easily become a victim of deception. Names are just hollow words. A certificate's fingerprint, on the other hand, is unique. It cannot be faked – as of the end of 2014. An SMTP client that pays attention to the fingerprint cannot be taken in by an MITM attack.

An SMTP client that performs opportunistic TLS does not combine a certificate's fingerprint with a specific identity. This only happens if the administrator assigns one or more (SMTP cluster) fingerprints in a target domain TLS policy (certificate pinning).

Certificate Pinning

Those who take certificate pinning seriously do not simply fix the fingerprint. They ascertain the identity beforehand and worry about the remote station's fingerprint. They would then look for a suitable partner in the target domain who could read out the used certificate's fingerprint. They can then compare the two fingerprints. The fingerprint can then be fixed if the two match – a rather complicated and labor-intensive process.

DANE SMTP also tackles this issue: It automates the identification. The TLSA RR publishes the fingerprint of the certificate used along with some descriptive statements about the certificate. A DANE-enabled SMTP client can retrieve this information in a trustworthy fashion via a DNSSEC-signed domain and compare it automatically with the fingerprint of the counterpart.

The Request for Comment (RFC) authors have even thought about a certificate's rollover. Anyone who wants to use a new certificate with a new fingerprint has to temporarily publish two TLSA RRs for the same resource (Listing 2 shows an RR example). For the SMTP client, it only matters that one of the published TLSA RRs fits. The old TLSA RR can be removed as soon as its DNS time to live (TTL) has expired.

$ dig TLSA _25._tcp.mail.sys4.de +short
3 0 1 9273B4E9040C1B9EE7C946EFC0BA8AAF2C6E5F05A1B2C960C41655E3 2B15CBE

Considering the aforementioned CA vulnerabilities, anyone who would like to switch to self-signed certificates will receive support from DANE SMTP once again. A TLSA RR allows publishing the fingerprint for a self-signed certificate or even just the reference to the root certificate from a proprietary CA. The signed DNSSEC domain co-signs in both cases.

Using DANE SMTP

A DNSSEC-verified DNS resolver is a prerequisite for DANE SMTP. It should work on the same host on which the DANE-enabled MTA is also operating. If a DNSSEC-enabled domain is having problems (e.g., with its signature), this is an indication of a security problem. Clients therefore are not allowed to use information about such domains because the reliability of the whole domain is called into question.

Conventional resolvers do not detect such problems. Only DNSSEC-enabled ones notice DNSSEC errors and suppress the response. If /etc/resolv.conf lists multiple resolvers, then they all need to be DNSSEC-enabled to ensure a seamless trust.

A final test makes sure that everything worked. Postfix should log Verified TLS … when transporting email to sink@dane.sys4.de :

Dec  9 13:44:23 mail postfix/smtp[14944]: \
  Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: \
  TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

The admin should set the smtp_tls_loglevel parameter to 1 to obtain this protocol.