One of the most underestimated security issues on the internet is probably the way that e-mail works. Mail systems make use of the SMTP protocol, which dates back to 1982, before modern security challenges had crossed anyone's mind. E-mail messages are transmitted via the internet in the form of readable text. That makes them easy to snoop on and even interfere with. Another problem is that a sender can easily pretend to be someone else. Crooks and troublemakers regularly use those weaknesses to their advantage.
In the Netherlands, there was recently a stir, when it came to light that lots of municipal authorities hadn't put proper e-mail security measures in place. Fortunately, many internet standards have gradually been modernised and made more secure, including the e-mail protocol. However, the improvements and extensions aren't in universal use.
The Dutch government actively encourages the use of up-to-date internet standards. One of the tools it uses is the so-called 'use or explain' list. The list has for some time included protocols designed to prevent interference with e-mail traffic, such as SPF and DKIM. Now the combination of STARTTLS and DANE has been added to the list.
TLS protection for e-mail
E-mail messages can nowadays be encrypted using TLS – the same protocol that's used to keep web traffic private. Whenever you see a padlock symbol by an HTTPS web address, it means that the data going back and forth is encrypted using TLS. A receiving server can indicate that it supports TLS; then sending servers use the STARTTLS command to say that they want to use that option. Many servers now have that capability.
However, unlike browsers, mail servers communicate with each other without human involvement. That has certain implications.
Also, in contrast to the situation with HTTPS, the use of TLS remains optional. A server can request an upgrade to TLS encryption, but the upgrade only takes place if both servers support the protocol.
Opportunistic security has vulnerabilities
Use of TLS by mail servers is a form of opportunistic security’, which unfortunately has vulnerabilities. A 'man in the middle' can block the upgrade signal that servers use to indicate support for STARTTLS. If the signal isn't received, the e-mail exchange will take place without encryption. Interfering with the process in that way is called a 'downgrade attack'. It results in messages being sent using the 1982 protocol, i.e. in readable form. A 'man in the middle' can also intercept mail by using a false TLS certificate.
DANE to the rescue
DANE plugs the security gaps in STARTTLS. With DANE, a server can use a separate channel – the DNS – to indicate that it supports TLS. The DANE signal also includes information about the server's TLS certificate, enabling verification. The separate channel makes use of DNSSEC, meaning that DANE signals can't be tampered with.
A complementary technology has also been proposed within the Internet Engineering Task Force (IETF), but it is not yet ready for implementation. The new technology operates on the 'trust-on-first-use' principle instead of using DNSSEC. That does unfortunately mean that it isn't 100 per cent secure, but the two technologies are not mutually exclusive. By contrast, STARTTLS+DANE provides complete security, because it requires the use of DNSSEC. The emergence of STARTTLS+DANE illustrates how DNSSEC works as an enabling-technology for new developments.
Various Dutch mail service providers, including XS4ALL and TransIP, have started using the STARTTLS+DANE combination, as has SIDN. In Germany too, a number of major mail service providers now support the two protocols. The German government advisory organ BSI also recommends that government bodies implement the two protocols. At https://internet.nl there's a mail security checker that lets you see whether a domain name's mail servers support the protocols.