StartTLS and DANE may be made mandatory for outgoing mail as well

The Forum for Standardisation wants to add various new standards to the 'use-or-explain' list, including StartTLS and DANE for outgoing mail.

Addition to the list would more or less oblige government and quasi-government organisations to implement the standards. In practical terms, all relevant standards on the 'use-or-explain' list have to be included in tender specifications for government contracts worth more than 50,000 euros, unless there are good reasons for their non-inclusion.

Together, TLS, StartTLS and DANE provide for a secure — i.e. cryptographically protected — connection for the transmission of e-mail messages. The three standards build on the existing DNSSEC infrastructure: RFC 7672 requires the use of DNSSEC with DANE.

Pinning TLS certificates

Many SMTP servers (MX gateways) already offer the option of enabling TLS, the same form of security as used in HTTPS for the web. Delivering mail systems can then use the StartTLS command to upgrade their TCP connections to TLS. Unfortunately, clients are not obliged to cooperate, and a man-in-the-middle can easily hide a server's StartTLS capability from a client (a 'downgrade attack'). Consequently, StartTLS is not a complete solution.

However, if the mail service's TLS certificate is pinned in a DNSSEC-secured TLSA record (on TCP port 25, by means of a hash), a client can be sure that the server in question supports TLS. The Postfix mail server (the most widely used MTA after Exim) can be configured to go through a DANE authentication procedure before delivering mail to an MX gateway.

Opportunistic protocol

The crucial difference between TLS for mail and TLS for the web (HTTPS) is that the use of 'https' in a URL implies that TLS must be used and that a dedicated TCP port (number 443) is available for the purpose. By contrast, with mail the client is not obliged to use TLS, meaning that DANE/TLS for mail is an 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and StartTLS has to encrypt its connections with a server that supports StartTLS and makes TLSA records available. However, if any of the support elements is missing, client and server fall back to TLS without DANE or even to insecure transmission. An opportunistic model with fallback provision was chosen to ensure that autonomous message delivery can proceed without human intervention wherever possible.

IANA did at one stage reserve a TCP port (number 465) for SMTP-over-SSL (SMTPS), but the arrangement was never standardised and the port has since been assigned to a completely different service. The sticking point is that there is no way of specifying in an e-mail address whether transmission should be secured, and a receiving mail system has no way of interacting directly with a sender, other than via a bounce. Consequently, with DANE/StartTLS the aim is to secure transmission 'wherever possible'.

REQUIRETLS

Encouragingly, efforts are being made to resolve the problem. This Internet Draft proposes the introduction of a REQUIRETLS keyword/capability and a RequireTLS mail header. The idea is that a sending system will be able to use the REQUIRETLS keyword to indicate that a message can be transmitted only via a TLS-secured connection. In other words, the security of the transmission will be prioritised over delivery of the message. Receiving servers will use the same keyword as a capability indicator to tell clients that REQUIRETLS is supported and to 'promise' that onward transmission will be exclusively via secure channels.

A message's sending host will also be able to use the RequireTLS header to indicate the importance of secure transmission. For example, the sending host could explicitly permit transmission via a non-secured connection only where no other option is available (delivery of the message thus taking precedence over the security of the transmission).

MTA Strict Transport Security

Another protocol currently under development is MTA Strict Transport Security (MTA-STS). With MTA-STS, the MX gateways for a domain and whether they require the use of StartTLS are specified in a policy file. The protocol uses a DNS TXT record to publicise the existence of the policy, but the policy itself has to be looked up using HTTPS. In other words, the existing system of CA certificates for the web is utilised for policy communication. Ultimately, the intention is to create a similar hierarchy of CAs for mail-systems.

The idea is that delivering mail systems will retain the policies for an extended period (weeks or months) and before making deliveries will check the validity of the MX gateways that they are pointed to by the DNS. To reduce the risk of an MITM attack, it will be necessary to proactively refresh your stored policies on a daily or weekly basis separately from any mail delivery. An MTA-STS configuration can be tested here.

A separate mechanism is being developed for reporting problems. Known as SMTP TLS Reporting (TLSRPT), the system can also be used for DANE. The mechanism is implemented in a similar way to the DMARC reporting mechanism.

MTA-STS is an initiative by Google in response to the slow adoption of DNSSEC, which is a prerequisite for the use of DANE. The protocol is therefore intended to work without DNSSEC, but consequently offers less security than DANE. That is because the content of the policy file is merely a copy of the MX RRset with a long TTL. Prolonged retention of the information means that MX redirect attacks and StartTLS downgrade attacks can be detected. The drawback is that MTA-STS assumes the existence of a valid policy which has previously been obtained without DNSSEC security. In other words, the trust-on-first-use principle is applied, as in the HSTS protocol. Furthermore, whereas DANE provides an anchor for a particular certificate (or chain), MTA-STS involves the creation of a new CA-based certificate system, introducing all the problems associated with the use of CA certificates on the web. However, MTA-STS deliberately avoids diminishing DANE security: if DANE is present but cannot be validated, then you cannot use an MX gateway that validates in accordance with MTA-STS.

Expert review

"In 2015, StartTLS and DANE were made mandatory only for incoming mail, because at the time there was limited market support for outgoing mail," says Han Zuidweg, Senior Advisor at Logius (which operates the Forum for Standardisation). "By contrast, there was adequate support for incoming mail."

"Testing of StartTLS and DANE for outgoing mail has recently started. We're in the process of approaching the people who were involved in the expert review in 2015. If there are others who would like to be involved (because addition to the 'use-or-explain' list will affect them, for example), there's scope for their inclusion. We expect to complete the expert consultation within a month. On 6 August, the resulting recommendation will be published for public comment, at which point anyone will be able to provide input."

Adoption

Like StartTLS and DANE for incoming mail, DNSSEC was added to the 'use-or-explain' list some time ago.

Recently, the Pan-governmental Digital Government Policy Forum (OBDO) expressed the ambition to achieve server-side StartTLS and DANE implementation for all government organisations by the end of 2019. Similar aims were previously formulated for protocols such as DNSSEC, DKIM, SPF and DMARC, but adoption has been slower than hoped. If StartTLS and DANE for outgoing mail are added to the 'use-or-explain' list, a further adoption target will be defined for those protocols.

StartTLS Everywhere

A variety of initiatives are currently being taken to promote the use of StartTLS. Here at SIDN, for example, we are in the process of extending the Registrar Scorecard to incentivise the use of StartTLS, DKIM, SPF and DMARC. That will involve making payments to registrars that enable the security standards for the .nl domain names in their portfolio.

Meanwhile, as a follow-up to the popular Let's Encrypt, the Electronic Frontier Foundation (EFF) recently launched StartTLS Everywhere. The EFF will supply a plugin for certbot that will enable the installation and maintenance of a Postfix certificate. Similar plugins are being developed for Dovecot and Sendmail.

The EFF will also maintain a list of domains that offer StartTLS in combination with a CA certificate, as with STS but centralised. In addition, the EFF portal has a tool for checking whether a mail domain uses StartTLS. A similar check can be done on the Internet.nl portal as well.

Comments

  • Monday 29 January 2018

    About SIDN

    New blood for our New Business Department

    Thumb-great-idea

    "You've got the opportunity here to introduce propositions that really add value."

    Read more
  • Wednesday 17 April 2019

    Internet security

    Salaries stolen using hacked e-mail addresses

    veilig+wachtwoord+tumbnail

    Tips on setting secure passwords

    Read more
  • Tuesday 26 February 2019

    About SIDN

    Future internets: building a better system

    Thumb-abstract-technical-background

    Netherlands needs to play a leading role again

    Read more

Sorry

Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.