SIDN to promote adoption of the DANE internet standard

E-mail security standard added to the Registrar Scorecard

For the second half of the year, we'll be adding the DANE internet standard to the Registrar Scorecard (RSC) -- our incentive scheme for .nl registrars. DANE needs to be implemented in order to receive a STARTTLS incentive payment. Our reasons for promoting DANE, and what it's all about, are explained below.

Use of modern internet standards is a must

Number of DANE-enabled mail domains growing exponentially

We want to encourage the use of modern internet standards through the RSC. We already promote IPv6, for example, because we see it as essential for improved, sustainable access on a constantly expanding internet. Various other, relatively new standards can also contribute to the security and reliability of the internet.

The most obvious example is DNSSEC. DNSSEC makes name-address translation (the DNS) much more secure by preventing scammers getting a falsified address accepted for a domain name. With the aim of improving e-mail security, we're also promoting the DMARC, SPF and DKIM standards. That trio of standards is intended to combat phishing, a common form of internet abuse. Our policy on e-mail standards is also aligned with the government's 'use-or-explain' list and NCSC advice.

STARTTLS (and its shortcomings)

It seems extraordinary now, but for many years a lot of data traffic was sent over the internet without encryption. The various protocols simply didn't allow for it. Fortunately, things are very different now. The basic web protocol, HTTP, doesn't provide for encryption, so an encrypted version was developed: HTTPS, which utilises additional Transport Layer Security (TLS). Most of us know HTTPS best as the (typically green) padlock in our browser address bar.

Originally, the e-mail protocol SMTP didn't use encryption either. E-mail messages were transmitted in plain text format, so that the content was visible to an interceptor. Interception remains a fairly common problem, unfortunately, even though there is now a TLS extension to the standard, called STARTTLS. We therefore encourage the use of STARTTLS through the RSC as well.

With STARTTLS, mail servers need to agree on use of the protocol before exchanging a message. If agreement is reached, the message should be sent in encrypted form.

However, the original STARTTLS system isn't watertight. An attacker can easily interfere with the 'conversation' about whether STARTTLS should be used, so that the mail servers fail to agree on encryption. In the absence of agreement, the servers fall back on the old non-encrypted transmission method. It's also possible for an attacker to inject a fake certificate, taking advantage of the fact that the servers don't check properly. An encrypted connection is then established, but the mail isn't secure from the attacker.

MTA-STS and DANE

Fortunately, there are protocols that address those issues: MTA-STS (which is still under development) and DANE. The developing MTA-STS standard is similar to the better-known HTST protocol. And it has the same flaw as that protocol: it follows the trust-on-first-use principle. In other words, another server's bona fides are initially taken on trust. So the system relies on there being no attacker active during the vulnerable first contact phase. After that, communication is secure. DANE doesn't have that vulnerability: it's secure from the outset. All the more so because, unlike MTA-STS, DANE leans heavily on DNSSEC.

The DANE protocol was originally used to increase website security. However, widespread adoption for that purpose was frustrated, mainly by the fact that not all end-users have the benefit of a DNSSEC-validating resolver. DANE is easy to use for securing STARTTLS on e-mail servers, and adoption for that purpose is proceeding at a healthy pace. The standard is also on the 'use-or-explain' list and accordingly recommended by the NCSC. As a result, government bodies are obliged to use it.

With additional DANE security, a STARTTLS connection is no longer facultative. A domain operator can now use DANE to say, "my mail server supports STARTTLS and, if yours does too, you must use it when we exchange mail." That means an attacker can't downgrade a session between two mail servers, by tricking the servers into using a non-encrypted connection. DANE therefore represents a big step towards secure e-mail, which is why we have added it to the list of modern security standards that we promote and incentivise through the RSC.