Dive into Email Security: MTA-STS Policies

In a nutshell: MTA-STS is a way to protect emails against interception (man-in-the-middle aka MitM attacks) between email servers. It partially resolves architectural issues in email protocols and is described in a recent RFC 8461 standard.

What is the issue MTA-STS resolves?

Historically, email protocols (SMTP, POP3, IMAP) transfer information in plaintext, making it possible to intercept, e.g. by accessing a communication link. This is how email delivery works:



Historically, Man-in-the-Middle attack was possible everywhere.

RFC 8314 standard requires using TLS between a mail user agent (MUA) and an email server. If your server and MUA match to RFC 8314, this mostly means elimination of Man-in-the-Middle attacks between MUA and mail servers:



Our Mail.ru email servers had already matched to RFC 8314 before the standard was adopted; it just reinforces best practices, so we had nothing to adjust. But if your email server still connects through unsecure protocols, you have to implement the standard. Because part of your users still has no encryption using email.

The mail client always works with one and the same mail server. So we can force all users to connect securely and then make unsecure connections technically impossible (as specified by RFC 8314). Sometimes it is hard to do, but still possible. Things get more complicated when it comes to traffic between mail servers. Servers are owned by different organizations and are often used like «install and forget». So we can’t quickly switch over to a secure protocol without loss of connectivity. STARTTLS extension, provided in SMTP, allows servers with encryption switch to TLS.

However, the attacker can know about using STARTTLS and make servers communicate over standard text protocol (so-called downgrade attack). For the same reason, certificate validity is not usually verified for STARTTLS. So an untrusted certificate can protect from passive attacks, which is no worse than sending an mail in plaintext. Thus, STARTTLS protects only from passive traffic sniffing.

MTA-STS partially resolves the mail interception issue between mail servers when the attacker can spoof traffic. If the recipient's domain publishes MTA-STS policy, and the sender's server supports MTA-STS, mail will be sent only through TLS connection. This applies only to servers specified by the policy, and only with the server's certificate validation.

Why partially? MTA-STS operates only when both parties have implemented this standard. MTA-STS does not protect if the attacker has obtained a valid domain certificate from a public CA.

How MTA-STS works

Recipient

1. Implements support for STARTTLS with a valid certificate. 
2. Publishes MTA-STS policy through HTTPS; special mta-sts domain and special well-known path are used, for example, https://mta-sts.mail.ru/.well-known/mta-sts.txt. The policy contains a list of mail servers (mx) to receive mail for this domain.
3. Publishes special TXT record _mta-sts in DNS with policy version. Whenever the policy is modified, this record should be updated (this prompts the sender to request it again). For example, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

Sender

The sender requests DNS record _mta-sts and policy through HTTPS (verifying the certificate). The obtained policy is cached (for the case if an attacker blocks access to it or spoofs DNS record).

When mail is sent, it is verified that:

• the destination server is listed in the policy;
• the server receives mail using TLS (STARTTLS) and has a valid certificate.

Benefits of MTA-STS

MTA-STS uses technologies that have already been used by most organizations (SMTP+STARTTLS, HTTPS, DNS). Implementation by the recipient does not require special software support for the standard.

Disadvantages of MTA-STS

You have to be sure that web and mail server certificates are valid, names are consistent, and updates are made on time. A problem with the certificate will make mail delivery impossible.

The sender is required MTA with support for MTA-STS policies; currently, there is no out-of-the-box support for MTA-STS in MTA.

MTA-STS uses a list of trusted root CA.

MTA-STS does not protect from attacks where a valid certificate is used. Generally, near-server Man-in-the-Middle attacks require that a certificate can be issued. Such an attack can be detected through Certificate Transparency. Generally, MTA-STS mitigates the risk of traffic interception but does not eliminate it.

The last two points make MTA-STS less protected than the standard DANE for SMTP (RFC 7672), but more technically reliable. For MTA-STS it is less probable that a mail will not be delivered due to implementation problems.

Competitive standard — DANE

DANE uses DNSSEC to publish certificates and does not require any external CA, which makes it much safer. However, the use of DNSSEC will result in more technical issues, according to statistics. But the reliability of DNSSEC and its technical support is progressing. Using of DANE in SMTP by recipient requires the availability of DNSSEC for the DNS zone. Proper support for NSEC/NSEC3 is significant for DANE, but DNSSEC has problems with it.

DNSSEC misconfiguration can lead to mail delivery failures if the sender supports DANE, even if the recipient knows nothing about it. So, despite DANE is an older and more secure standard, and it is supported by some sender's server software, many organizations don’t want to use it because of DNSSEC. This has significantly slowed down the adoption of DANE.

DANE and MTA-STS can be used together.

What about support for MTA-STS in Mail.ru service

Mail.ru has been publishing MTA-STS policy for all major domains since this year. Now we are implementing the client part of the standard. At the time of this publication, policies are used in non-blocking mode (when delivery is blocked by policy, an email will be delivered through a «spare» server without policy application). Later blocking mode will be forced for a small portion of SMTP traffic, and later we’ll apply the policy for all the traffic.

Who else supports the standard

MTA-STS policies are published by approximately 0.05% of active domains that protect a large amount of mail traffic: Google, Comcast, and, partially, Verizon (AOL, Yahoo). Many other email services are going to implement the standard in the nearest future.

How this will affect me?

In no way, if your domain does not publish MTA-STS policy. If you do publish the policy, then emails for your users will be better protected from interception.

How should I implement MTA-STS?

Support for MTA-STS on recipient's side

It is enough to publish policy through HTTPS and make a record in DNS, configure a valid certificate from a trusted CA (it can be «Let’s encrypt») for STARTTLS in MTA (STARTTLS is supported in all modern MTA); no special support from MTA will be required.

Stepwise, it looks as follows:

1. Configure STARTTLS in your MTA (postfix, exim, sendmail, Microsoft Exchange, etc.).
2. Use valid certificate (issued by a trusted CA, not expired, subject of the certificate matches the MX record used for mail delivery for your domain).
3. Configure TLS-RPT record for reports delivery of policies using (by services that support sending of TLS reports). For instance (for domain example.com):
   
   

   smtp._tls.example.com. 300 IN TXT "v=TLSRPTv1;rua=mailto:[e-mail]"
   

   
   This record instructs to send statistical reports on the use of TLS in SMTP to address [e-mail].
   
   Monitor the reports for several days to ensure that there are no errors.
4. Publish MTA-STS policy through HTTPS. The policy is published as a text file with string terminators CRLF according to location.
   
   

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   
   Policy example:
   
   

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   
   The version field contains the policy version (now it is STSv1).mode sets the mode of policy application, testing means test mode (policy is not applied), and enforce stands for operational mode. 
   
   First, publish the policy with mode: testing, and if no policy problems arise, you can switch to mode: enforce.
   
   All email servers which can receive mail for your domain are listed in mx (for each server, configure a certificate matching the name specified in mx). Max_age specifies a time of policy caching (once saved, the policy will be applied even if the attacker blocks its delivery or spoofs DNS records during the caching; modify mta-sts record in DNS if you need to request policy again).
5. Publish TXT record in DNS: 
   
   

   _mta-sts.example.com. TXT "v=STSv1; id=someid;"
   

   
   An arbitrary identifier can be used in id field (timestamp); it should change with policy modification — this lets the sender know that a cached policy needs to be requested again (if the identifier differs from the cached one).

Support for MTA-STS on the sender's side

It is limited as yet since the standard is new:

• Exim — no internal support, but there is a third-party script;
• Postfix — no internal support, but there is a third-party script described in detail on pypi.org.

End title: about «mandatory TLS»

Regulators have been increasingly focusing on email security (which is good news). For example, DMARC is mandatory for all government agencies in the U.S. and is increasingly required in the financial sector, adoption in regulated sectors reaching 90%. Some regulators now require using «mandatory TLS» with well-known domains. However, the way for supporting «mandatory TLS» is not defined, and implementing this setting often does not protect from actual attacks, which have already been accounted for in DANE or MTA-STS.

If the regulator requires the implementation of «mandatory TLS» with separate domains, we recommend using MTA-STS or its partial equivalent as it doesn’t require to make safe settings for each domain individually. If you have difficulties with the implementation of the client part of MTA-STS (you probably will until the protocol is widely supported), here is a recommendation:

1. Publish MTA-STS policy and/or DANE records (better to add DANE only when DNSSEC is already enabled for your domain, and MTA-STS in any case), this will protect your inbound traffic and you don’t need to request other email services to set up mandatory TLS for your domain when the email service already supports MTA-STS and/or DANE.
2. For major email services, implement an «equivalent» of MTA-STS through separate transport settings for each domain which will configure MX used for relaying mail and will require verification of TLS certificate for it. If domains already publish MTA-STS policy, this, most probably, can be done smoothly. The enabling of mandatory TLS without configuring a relay and verifying a certificate doesn’t protect you and doesn’t improve STARTTLS protection.