Jump to content

# TLS-RPT, DANE and MTA-STS

From ArchWiki

There are two key elements in how we trust email. One is about validating the content and sender of the message which includes messsage encryption as well as DMARC (RFC 7489), DKIM (RFC 6376), SPF (RFC 7208) and ARC (RFC 8617). The other is about trust in the mail servers themselves and that is what this article addresses.

According to RFC 3207 publicly reachable email servers need to be reachable without TLS encryption. This leaves servers vulnerable to downgrade attacks to plaintext transmission. Furthermore, a certificate doesn't need to meet any requirements of validity in practice, as RFC 3207 specifies none. In order to protect against this, two technologies have emerged with more and more of the large email providers supporting them as well: DANE and MTA-STS. Either technology informs an email sender that TLS is available and plaintext should not be used for transmission. They also both validate the certificate presented in their own way. An additional protocol named TLS-RPT exists that allows for informing the operator of an email server about any problems relating to the TLS configuration and thus preventing emails not reaching their destination. This article explains how to deploy these three technologies.

Please be aware that MTA-STS and DANE should be deployed together if possible, instead of just having one of them. They are designed not to interfere with one another and the support for both varies with mail senders. As discussed later in the article, Postfix and Exim do not have MTA-STS support built-in. Any sender using either of these can only work with DANE unless some extra work is done (see below). Similarly, DANE requires DNSSEC and not every mail provider supports this extension. Currently, the largest email provider in the world, Google Mail, does not use DANE or DNSSEC and relies on MTA-STS exclusively.

When using MTA-STS a TLS certificate needs to be from a valid certification authority and be currently valid for the hostname of the email server. DANE on the other hand relies on leveraging DNSSEC to provide authenticity of the certificate. However, DANE needs a sender to use a DNSSEC validating DNS resolver and in the inbound direction, the domain to be enrolled with DNSSEC. This might not be possible with every DNS registrar. In such a situation, only MTA-STS can be used in the inbound direction, but it may still be used together with TLS-RPT. When combining both technologies, as is recommended, the certificate presented could be validated by either one, and thus needs to have a current DNS record for DANE and be signed by a trusted root CA.

The German national security standard BSI TR-03108 mandates the use of all three mechanisms in unison and this is generally considered good practice.

## Inbound

In this section, the inbound direction is discussed, that is to say the setup to enable other mail servers to send mails to your server.

### MTA-STS

Mail Transfer Agent - Strict Transport Security (MTA-STS) is a technology that allows mail servers to declare their ability to receive Transport Layer Security (TLS) connections. It also provides for specifying a policy that requests that sending SMTP servers should refuse to deliver, or not, if the receiving server does not provide a trusted server certificate.

Note RFC 3207 only says that clients and servers should ensure that "an acceptable degree of authentication and privacy was achieved" when establishing a TLS connection. In particular it does not specify any sort of validation like the certificate being issued by a trusted CA, the certificate matching the server, or the certificate passing revocation checks. When using MTA-STS, validation is required by RFC 8461, Section 4.2, with the client being mandated to ensure the certificate is signed by a trusted root CA, not expired and has a Subject Alternate Name (SAN) matching the server's hostname. Revocation checking is left up to the client but permitted, and so the certificate needs to be in good standing.

MTA-STS works by publishing a DNS entry and hosting a policy file at `https://mta-sts.<domain>/.well-known/mta-sts.txt`.

The DNS entry is a `TXT` record published at `_mta-sts.<domain>`. It is of the following form:

    v=STSv1; id=202408090200Z

The `v=STSv1` field is the revision of MTA-STS that is deployed, this is 1 for now. `id` is an alphanumeric field with 1-32 characters. Every time it is increased, the MTA-STS policy is considered to have been changed. Good practice is to create a string representing the current date and updating it if any changes are made to the policy.

Finally the policy is a text file of the following kind:

    version: STSv1
    mode: enforce
    max_age: 10368000
    mx: mail.example.org
    mx: *.example.org

There are three distinct modes:

none
  informs senders that there is no policy, and this effectively disables MTA-STS
testing
  means that the policy should be considered inactive, but TLS-RPT reports should still be made. This mode only makes sense if TLS-RPT has been configured.
enforce
  is the mode that tells senders to refuse connection to the server if no connection over TLS can be made.

`max_age` is the lifetime of the policy in seconds. This should be somewhere between several weeks, but less than 31557600 (roughly a year). The `mx` field simply has to lists all `MX` records for the domain.

### DANE

Warning DANE requires the domain to be enrolled with DNSSEC. It cannot function otherwise.

DANE is an abberviation of DNS-based Authentication of Named Entities. It is a security protocol that uses DNS to verify the authenticity of digital certificates associated with a domain name. It is designed as an alternative to certificate authorities (such as Letsencrypt) by utilizing the integrity of DNSSEC to ensure that a certificate indeed belongs to a domain name. While DANE is applicable to any certificate, in practice it is only used for email, or DANE SMTP. By design, the private keys and certificates can be self generated. While it is also fine to use CA provided certs its just not needed at all and they don't provide any significant benefit. One key goal of DANE is to protect against man in the middle attacks. DNSSEC, or Domain Name System Security Extensions, is what guarantees the integrity of the public key published via DNS and therefore DANE cannot be used without it.

This section is focussed on how to use DANE specifically with SMTP. How to create a DANE TLSA record with OpenSSL is a more comprehensive guide on everything relating to DANE.

The way DANE works is by leveraging DNSSEC to publish the hash of a certificate in DNS in the form of a special TLSA record. For email there are two usable options:

DANE-TA
  publishes the certificate of the certificate authority that signed the TLS certificate the email server uses. This would for example be the root certificate of Let's Encrypt, if that service is used.
DANE-EE
  works by publishing the hash of the certificate itself that is used by the email server.

It is possible to publish either the entire certificate or just the public key embedded in it. The latter option allows for reusing a key pair of a certificate and thus never having to change the DNS entry. When publishing the entire certificate, it is necessary to update the TLSA record every time a new certificate is issued by the certificate authority. This can happen quite regularly if ACME is used with for example Let's Encrypt.

Warning Reusing a key pair is seen as somewhat less secure than using changing key pairs.

A TLSA record consists out of three numeric fields and the certificate data. For example, it could look like this:

    _25._tcp.mail.example.org

    3 1 1 3a8a378f19eef5c90f783ba44f8d0e8648e883926b16f1dfaf94eef9e1602531

The record name is of the format `_[port]._[protocol].[service url]`. For SMTP, this would mean the port is 25 and protocol is TCP.

The numeric fields are as follows:

1. The first field is the type of DANE that is being used, called the Certificate Usage Field. A value of 2 is DANE-TA, 3 means DANE-EE. The values 0 and 1 are unsuitable for email and should not be used.
2. The second field, called Selector Field, indicates whether the full certificate Cert(0) or just the public key of the certificate SPKI(1) is being published.
3. The third field is called Matching Type Field and indicates how the data is published. A value of 1 is an SHA2-256 hash. The other possible options are generally considered unsuitable for practical purposes and therefore are not discussed here.

Note RFC 7672 recommends using the combination "DANE-EE(3) SPKI(1) SHA2-256(1)" with "DANE-TA(2) Cert(0) SHA2-256(1)" as a second choice.
Note Using a full certificate or the public key only has no security implications when used in a DANE-EE record. There's no particular advantage of either choice, other than SPKI(1) allowing for reusing a key pair when reissuing certificates. When using SPKI(1), the DNS record does not require any changes on a certificate reissuance. For DANE-TA, the choice is discussed in RFC 6698, Appendix A.1.2.2 and RFC 7672, Section 3.1.2. It is recommended using the matching type Cert(0) together with DANE-TA. Otherwise, it would be possible for an intermediate CA to have its certificate reissued with a different certificate content and the same keypair. In such a situation, certificate restraints could be violated.

Finally, the data field would be the SHA2-256 hash of the certificate or public key respectively. In order to compute this, openssl can be used.

    Hashing the full certificate (option 0)

    openssl x509 -in certificate.pem -outform DER | sha256sum

    Hashing the public key only (option 1)

    openssl x509 -in certificate.pem -pubkey -noout | openssl ec -pubin -outform der | sha256sum

In the case of DANE-EE, `certificate.pem` would be the actual TLS certificate used by the email server. On the other hand, with DANE-TA, this would have to be any of the issuing CAs certificates.

Note It is possible to use a matching type of 2 in order to use SHA2-512 instead of SHA2-256. This is not recommended, as RFC 6698 makes implementing SHA2-512 support optional, and not all resolvers may support it. RFC 7672 also discourages this and recommends using SHA2-256 TLSA records instead.
Warning On its own, DANE-EE could be deployed with a self-signed or untrusted (non-CA) certificate, or even an expired certificate. Similarly, DANE-TA could be used with any CA.

However, some large email corporations enforce MTA-STS even when DANE is available - notwithstanding RFC 8461 - and will therefore drop the connection to your mail server if you do not have a CA certificate.

Practically speaking, then, it is necessary to present a CA certificate, meeting the requirements above, when both DANE and MTA-STS are deployed.

Depending on the DNS provider, it may be possible to automate the publication of this record. gotlsaflareAUR for example allows for publishing the record to the Cloudflare DNS service. Given the multitude of providers out there, it is not possible to give any specific instructions for this step.

There is also the dns_toolsAUR package for managing DNS servers that are using DNSSEC and ssl-mgrAUR for creating and renewing Let's Encrypt certificates, creating and updating DANE TLSA records and for rolling the keys when certificates are renewed. For more information on these, see the documentation dns_tools docs and ssl-mgr docs.

Warning Since DNS records are cached for a time given by the TTL, updating a TLSA record has to be done step-by-step where first the new record is added, the TTL is waited out and then finally the previous record is deleted and the mail server switched to the new certificate. This process is known as performing a key roll

### TLS-RPT

SMTP TLS Reporting (TLS-RPT) defined in RFC 8460 is a standard for reporting mail delivery problems related to TLS encryption failures and successful connections.

TLS-RPT works by publishing a DNS record informing senders where to send the reports about TLS functionality. There is only one type of reports, aggregate reports, which summarize how often a particular outcome, be it error or success, happened. It is formatted as an XML file for further processing.

A TLS-RPT record is a `TXT` record published at `_smtp._tls.[domain]`. The content has to start with a version indicator `v=TLSRPTv1;` followed by information on where the reports are to be sent. This could either be a mail address or an HTTPS service accepting POSTs. A complete record would look like this:

    _smtp._tls.example.org

    v=TLSRPTv1; rua=mailto:tlsrpt@example.org

`rua` indicates that aggregate reports are to be sent to this address, `mailto:` specifies this should be done via mail. `https:` would be the prefix for the HTTPS POST solution.

Warning It is strongly advised not to use HTTPS POST endpoints for reporting. BSI TR-03108 forbids this in fact. While email can be authenticated with DMARC, the HTTPS POST mechanism cannot. An attacker could send fraudulent reports to try to obscure interference.

As the reports are XML formatted, it is recommended to process them in order to extract information. There are also numerous cloud service providers available that can receive and process these reports. There is also tls-rpt available in the dmarc_reportAUR package which can generate human readable reports for both DMARC and TLS-RPT from the XML files. For more info on this please see dmarc_report Readme

## Outbound

Next, the outbound direction (i.e. when sending emails) is discussed. Unlike the inbound direction, where all three technologies are mostly independent of the mail transfer agent used, the steps for direction differ depending on which mail server is being used.

One thing in common for all MTAs is that it is necessary for sending TLS-RPT reports that all mail servers handling outgoing mail need to support the RFC 8689 extension, as TLS-RPT reports have to be sent with the header `Require-TLS: no`.

Additionally, a DNSSEC capable DNS resolver is required for resolving DANE and strongly recommended for MTA-STS, as it is otherwise possible to downgrade the connection. The following sections assume that DNSSEC is being used for DNS, and this is not repeated every time.

### Postfix

Postfix has long since supported DANE (as of Postfix 2.11), but MTA-STS and TLS-RPT rely on plugins.

Note TLS-RPT and RFC 8689 are only supported with Postfix 3.10 and newer. In order to send reports, all outgoing mail servers in a Postfix setup need to be at least on that version.

#### DANE

DANE is built-in to Postfix and requires only the following lines to be added to `/etc/postfix/main.cf`

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane

#### MTA-STS

In order to support MTA-STS, a plugin is needed to supply information on the TLS policy to Postfix through smtp_tls_policy_maps. There are two options available for this, postfix-tlspol and postfix-mta-sts-resolverAUR.

Note postfix-mta-sts-resolverAUR faces the problem that it cannot resolve DANE and thus overrides DANE if both MTA-STS and DANE are deployed on a server. This problem is discussed by the project here. postfix-tlspol has no such limitation and is also better optimised.

Install the postfix-tlspol and start or enable the `postfix-tlspol.service`. Then edit the `/etc/postfix/main.cf` of Postfix to add the following lines

    smtp_dns_support_level = dnssec
    smtp_tls_security_level = dane
    smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8642:QUERYwithTLSRPT

Note `postfix-tlspol` resolves both MTA-STS and DANE at the same time and thus requires DANE and DNSSEC to be enabled as well.

#### TLS-RPT

Note For TLS-RPT to be useful, at least DANE or MTA-STS (ideally both) have to be already configured.

Install tlsrpt-reporter. Adjust at least the following lines in `/etc/tlsrpt/reportd.cfg` to fit your domain and organisation:

    organization_name = EXAMPLE.COM
    contact_info = tlsrpt@EXAMPLE.COM
    sender_address = noreply@EXAMPLE.COM

Afterwards, start or enable `tlsrpt-collectd.service` and `tlsrpt-reportd.service`. Then, add the following lines to your Postfix `/etc/postfix/main.cf`:

    smtp_tlsrpt_enable = yes
    smtp_tlsrpt_socket_name = /run/tlsrpt/tlsrpt-collectd.socket

Note It is possible to run `tlsrpt-collectd.service` and `tlsrpt-reportd.service` on different systems. Consider the `fetcher` option in tlsrpt-reportd(1).
Warning There is currently an issue that causes `tlsrpt-reportd.service` to output repeated errors if `tlsrpt-collectd.service` has not been running for at least a day. This does not affect functionality and has already been fixed upstream and should thus be resolved in the next release.

### Exim

Exim only supports DANE and not MTA-STS or TLS-RPT. In order to activate DANE, edit `/etc/exim/exim.conf` and add

    dns_dnssec_ok = 1

Furthermore, edit the `remote_smtp` transport and add the following line to it

    hosts_try_dane = *

Further information on this topic can be found in the Exim documentation.

### Stalwart

Stalwart has all three of DANE, MTA-STS and TLS-RPT built-in already. Please see their documentation for instructions on how to enable and configure them.

Category:

- Mail server

TLS-RPT, DANE and MTA-STS
Add topic