11/20/2019 | Press release | Distributed by Public on 11/19/2019 20:36
The Simple Mail Transfer Protocol (SMTP) is used for mail transport between mail servers and is traditionally not secured, making it vulnerable for eavesdropping.
DNS-based Authentication of Named Entities (DANE) for SMTP provides a more secure method for mail transport and is increasingly becoming more popular. Domains with DANE records include comcast.net, debian.org, gmx.de and protonmail.ch.
In this post we will discuss the risks associated with SMTP and how DANE helps to overcome these, as well as provide you with a list of tips that we at Internet.nl suggest to those looking after mail servers when implementing DANE.
Risks of opportunistic SMTP using STARTTLS
By default, mail transport happens in plain text. With the introduction of the STARTTLS extension, opportunistic security was added to the SMTP protocol. This means that mail transport between mail servers is only secured when the receiving mail server requests the sending mail server to use an encrypted Transport Layer Security (TLS) connection. This is illustrated in Figure 1.
Although STARTTLS can encrypt mail transport, the encryption is not enforced and there is no authentication of the receiving mail server by the sending mail server. This leads to the following risks.
Risk 1: STRIPTLS / downgrade attack
First of all, a sending mail server has no means to determine beforehand if the receiving server supports encrypted transport. It's only after the communication has begun that the sending server may learn from the features the receiving server supports (in this case STARTTLS) that it allows for encrypted transport.
As a result, the initial connection from one mail server to another always starts unencrypted making it vulnerable to man-in-the-middle (MITM) attacks. If a mail server does not offer the 'STARTTLS capability' during the SMTP handshake (because it was stripped by an attacker), transport of mail occurs over an unencrypted connection.
Risk 2: Divert mail traffic to attacker's mail server
Secondly, mail servers by default do not validate the authenticity of another mail server's certificate; any random certificate is accepted. While the delivery of mail was traditionally considered to be more important than the security of mail, from a more technical perspective it was unclear which names to verify in the certificate.
Hostnames for mail servers are obtained via DNS Mail eXchanger (MX) lookups, but without DNSSEC, these names cannot be trusted. As a result, an attacker can insert any random certificate into the connection process.
In need of a more secure mail transport
Research and incidents have shown that these attacks are not theoretical but are happening in daily practice leading to the leakage of information. We need a more secure mail transport method in order to neutralize an attacker's attempt to defer and/or tamper mail transport. This is where DANE for SMTP comes in.
DANE for SMTP (RFC 7672) uses the presence of DNS TLSA resource records to securely signal TLS support and to publish the means by which sending mail servers can successfully authenticate legitimate receiving mail servers. This makes the secure connection resistant to downgrade and MITM attacks.
The previously described risks of SMTP with opportunistic TLS can be mitigated by using DANE. This is illustrated in Figure 4, which shows mail transport using DANE.
When using DANE, it is a best practice for the sending mail server to abort the connection and try another server or defer the message whenever the certificate does not validate.
For those wondering about MTA-STS as an alternative to DANE: this relatively new method seems mostly suitable for the large cloud mail providers, is not adopted as widely as DANE, and is considered less secure than DANE because of trust-on-first-use and caching, which is acknowledged in RFC 8461. However, you can use it next to DANE since both standards can intentionally co-exist next to each other.
Tips and tricks for implementing DANE
If you're planning on implementing DANE, here a couple of tips and tricks.
First publish DANE records on your MX domains or ask your mail provider to do so.
The next step is to enable DANE verification on your sending mails servers (or ask your provider/vendor to enable or implement it). Our how-to might be useful for these steps.
Note: DANE is backwards compatible. So, if your mail server supports DANE and a connecting mail server does not support it yet, usually STARTTLS or plain text still will be used.
Publishing DANE records
Verifying DANE records
Support by mail providers
DANE is supported by an increasing number of mail providers, like Comcast, GMX, Mailbox.org, One.com, Posteo and XS4ALL. DANE is not supported yet by Microsoft Office 365. However, on the Office 365 UserVoice Forums, the feature request for DNSSEC and DANE is the second most popular in the category 'Security & Compliance'. Google already offers alternative DNSSEC-signed MX hosts for G Suite (mx[1-4].smtp.goog) that a user can configure. There is also a request for DANE on Google's feature ideas platform that G Suite users can support.
Test your own domain
If you are interested in learning more tips and tricks on implementing DANE, please take a look at our DANE for SMTP how-to. Feel free to contribute!
Contributors: Special thanks to Bart Knubben, who works for the Dutch Standardisation Forum for his contributions to this blog.
Dennis Baaten is a freelance security consultant and works for the Dutch Internet Standards Platform where he operates the support desk of Internet.nl and develops technical how-to guides on implementing secure Internet standards such as DANE.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.