DANE

TL;DR

DNS-Based Authentication of Named Entities (DANE) is an internet standard that leverages DNSSEC and the TLSA DNS resource record to augment (or even replace) the Public Key Infrastructure (PKI). When DANE is used in combination with SMTP, it forces the sender to use TLS encryption (STARTTLS) for the SMTP session, much like MTA-STS does.

With DANE, a TLSA type DNS Resource Record is placed in a domain DNS zone, which can then be used to authenticate x.509 certificates. By requiring DNSSEC, the client can authenticate the TLSA record itself, to build a chain-of-trust.

DANE can work with all TLS encrypted communication protocols, including SMTP services that use rfc3207 SMTP over TLS (STARTTLS).

DANE can be used to augment the traditional PKI by adding certificate pinning, this way DANE can help prevent man-in-the-middle and downgrade attacks.

DANE and the TLSA resource record are originally specified in rfc6698, and later updated in rfc7671. DANE usage in combination with SMTP is detailed in rfc7672.

DANE vs PKI

DANE has the potential to leverage DNSSEC as a replacement for the Public Key Infrastructure (PKI), on which the chain of trust on the internet is currently based. However, there are concerns about the safety, resilience and robustness of the DNS. Security researchers have argued that DANE is not a viable replacement of the PKI.

In this article we'll restrict ourselves to exploring DANE as an augmentation of the existing PKI in the form of certificate pinning. We do not recommend attempting to use DANE as a PKI replacement in a production infrastructure.

With this article being part of the email hardening guide, we'll explore DANE in combination with SMTP, but the knowledge obtained from this article should also apply to other services such as HTTPS.

The TLSA DNS Resource Record

DANE uses the 'TLSA' DNS Resource Record, which is specified in rfc6698. A TLSA record contains information on an x.509 certificate that is to be expected from the service that is being connected to (such as HTTPS web services, or SMTP services).

The TLSA record is placed at DNS address _[port]._[protocol].[domain], for example:

_25._tcp.example.mailhardener.com

The TLSA record in this example would be used for TCP services on port 25 (which is SMTP) at example.mailhardener.com.

DANE with SMTP

When combined with SMTP, DANE serves two purposes:

• Force the sender to use TLS encryption for email delivery. The sender will not fall back to plain-text communication in case the TLS handshake fails, instead it will not deliver the email and try again later. This prevents downgrade attacks.
• Perform certificate pinning on the SMTP service. This helps ensure that senders cannot be tricked into delivering email to a rogue email service (known as a man-in-the-middle attack).

Note that if the domain does not support DNSSEC, then DANE cannot be used. In that case MTA-STS can be used to enforce TLS encryption for inbound email.

Example: A DANE capable SMTP service needs to deliver email to example.mailhardener.com, SMTP works on TCP port 25.

1. The sender (the sending SMTP service) will first query the DNS for TLSA records at _25._tcp.example.mailhardener.com. If TLSA records are returned, its contents are extracted and stored. The sending SMTP service must also verify the DNSSEC chain here, to ensure the fetched TLSA record is authentic.

2. The sender connects to the SMTP service at example.mailhardener.com, and issues the STARTTLS command. In the following TLS handshake sequence, the SMTP service at example.mailhardener.com responds with a certificate.

3. Finally, the sender will verify that the certificate matches at least one of the TLSA DNS records, before continuing the TLS handshake. If the certificate does not match any of the TLSA DNS records, this is an indication that the SMTP service is not to be trusted. In that case the TLS handshake is aborted and the email will not be delivered.

DANE and SMTP TLS reporting

rfc8460 SMTP TLS reporting is a reporting protocol used to report TLS related issues with SMTP. SMTP TLS reports contain the TLS authentication results as seen from the sender's perspective.

SMTP TLS reporting supports reporting DANE related failures, the following 3 DANE related failures can be expected in SMTP TLS reports:

When DANE is used, it is highly recommended enabling SMTP TLS reporting for the domain, and using a report aggregation service such as Mailhardener to monitor for any TLS related email delivery issues.

Benefits

Using DANE in combination with SMTP adds a trust anchor for the connecting party to authenticate the certificate. This can help against downgrade attacks, and Man-In-The-Middle attacks. DANE can also be leveraged as an effective certificate revocation method, in case a key is compromised.

The achieved result is similar to that when MTA-STS is used, except that with DANE trust is placed in the DNSSEC root keys, whereas with MTA-STS trust is placed in a Certificate Authority.

Downsides

As with any form of certificate pinning, implementing DANE adds additional maintenance requirements. A certificate renewal, or key rotation will require updating (or rather: rotating) the TLSA records. Failure to do so may result in undeliverable email.

Another downside is that with DANE, more trust is now placed in DNSSEC, which many argue is not robust, nor cryptographically sufficient.

Finally, as with MTA-STS, DANE has a 'bootstrap' problem, it relies on a DNS record to discover the existence of a TLSA record. If an attacker can block the DNS query for the TLSA record (likewise the MTA-STS assertion record), the sender will not be aware of the DANE support of the service. In practice though, this kind of attack is very hard to perform, and DNSSEC NSEC3 should prevent this kind of attack from being practical.

Before adopting DANE for SMTP, considerations must be made whether the security benefits of DANE outweigh the risks.

TLSA record format

DANE uses the TLSA DNS resource record, which is specified in rfc6698.

The TLSA DNS resource record contains 4 fields:

• The certificate usage field (integer)
• The selector field (integer)
• The matching type field (integer)
• The Certificate Association Data field (string)

[usage] [selector] [matching type] [certificate association data]

For example:

3 0 1 370c66fd4a0673ce1b62e76b819835dabb20702e4497cb10affe46e8135381e7

Certificate usage field

The certificate usage field specifies which type of the certificate is represented in the Certificate Association Data field. In the DANE specification (rfc7671), slightly different names are used for the usage fields.

In rfc7671, section 5.1, the DANE-EE (3) usage has been updated. It states that with DANE-EE (3) no domain-name validation should occur (and also no expiry date validation). This makes it practical for SMTP services which accept email for a large number of domains to adopt DANE.

rfc7672 ('SMTP Security via Opportunistic DANE') specifies DANE usage in combination with SMTP. Section 3.1.3 of rfc7672 explains why usage PKIX-TA (0) and PKIX-EE (1) should not be used with SMTP.

Hence, for SMTP in combination with DANE, only DANE-TA (2) and DANE-EE (3) should be used.

Selector field

The selector field specifies which part of the certificate is represented in the Certificate Association Data field.

When using option 0, the TLSA record must be replaced every time the certificate is renewed or replaced.

When using option 1, the TLSA record must be replaced when the private key (and thus the public key) of the certificate owner changes. In a typical application, this is the key-pair that is created by the certificate owner during creation of the CSR.

Matching field

The matching field specifies how the certificate should be matched to the Certificate Association Data field. This applies to the content specified in the Selector field.

In practice, option 0 is only practical in combination with a selector of type 1 (SubjectPublicKeyInfo), due to the resulting size of the Certificate Association Data field.

DANE capable services are not required to support SHA2-512, so in practice, only option 1 (SHA2-256) should be relied on.

Certificate Association Data field

The fourth and final field in a TLSA DNS resource record contains the data as described in the 3 previous fields.

For example: if usage=1, selector=0 and match=1, then the Certificate Association Data field should contain the SHA2-256 hash digest of a full DER encoded certificate issued by a PKI CA.

TLSA record example

Consider the following DNS record:

_25._tcp.mail.example.com. TLSA 3 1 1 (E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )

We can decode this record as follows:

Meaning that:

• The TLSA record applies to a tcp service on port 25 (SMTP) at mail.example.com.
• The contained data is the SHA2-256 hash of the subject public key in the certificate.

Rotating TLSA records

Whenever a certificate is renewed (with selector=0), or when a key is rotated, a new TLSA record must be published before the new certificate is installed, whilst keeping DNS propagation delays in mind.

Unlike for example with DKIM selectors, it is allowed for a DNS query to return more than one TLSA record. The receiver will accept the certificate if any of the TLSA records match. This allows for graceful rotation of the TLSA record.

The order of operation for rotating a TLSA record is as follows:

1. A new certificate is created, but not yet installed
2. A new TLSA record is created for the new certificate, and placed in the DNS zone
3. A grace period is recommended, to allow for DNS propagation (for example: 24 hours)
4. The new certificate can now be installed
5. After an additional grace period (for example: 48 hours), the old TLSA record can be removed.

TLSA with third-party SMTP services

For SMTP services where TLS is applied (this only applies to inbound email), the certificate, and therefore the TLSA record, must be applied to the domain of the MX service.

For example: example.com uses Microsoft 365 services. The MX records for example.com will point to the *.onmicrosoft.com domain. The certificate presented by the Microsoft 365 SMTP service will be for onmicrosoft.com, not example.com. Hence, the certificates, and therefore the TLSA records are managed by Microsoft, not the customer.

So, third party SMTP providers that implement TLSA will place and manage the TLSA record under their own domain. The customer (which is you) should not have to perform any changes to their infrastructure.

Creating a TLSA record

For self-hosted (or on-premise) SMTP services, a TLSA record can be published to enable DANE certificate pinning, which protects DANE capable senders from man-in-the-middle attacks during delivery of email to your domain.

WARNING: Before adopting DANE, ensure that you understand the concepts of TLS certificate pinning. Also ensure that proper monitoring and procedures are in place to ensure that the certificates remain valid, and the TLSA records match the certificates. Failure to do so may result in email delivery failures.

Prerequisites:

• The DNS zone must have DNSSEC enabled
• The DNS service provider must support TLSA
• The SMTP service must support STARTTLS command
• The SMTP service must serve a valid x.509 TLS certificate

Step 0: Ensure the SMTP services serve a valid certificate.

Step 1: Choose with kind of selector you want to use:

Step 2: Generate the TLSA record value, using openssl:

# When using selector=0 (Full Certificate) on the certificate:
openssl x509 -in certificate.pem -outform DER | sha256sum

# When using selector=1 (SubjectPublicKeyInfo) on a certificate:
openssl x509 -in certificate.pem -pubkey -noout | openssl ec -pubin
 -outform der | sha256sum 

# When using selector=1 (SubjectPublicKeyInfo) on the private key:
openssl ec -in private.pem -pubout -outform DER | sha256sum

# When using selector=1 (SubjectPublicKeyInfo) on the public key:
openssl ec -pubin public.pem -outform DER | sha256sum

Note that we use openssl ec here, and not openssl rsa. The ec command should accept both ECC and RSA keys, whereas the rsa command doesn't. If your OpenSSL client does not support elliptic curve cryptography, then replace ec with rsa. Many thanks to Wolfgang Kraft for this tip!

See also: how to create a DANE TLSA record with OpenSSL

Step 3: Create the TLSA record, the full TLSA record should be in the format:

[usage] [selector] [matching type] [data]

For example:

3 0 1 370c66fd4a0673ce1b62e76b819835dabb20702e4497cb10affe46e8135381e7

Alternatively, use a TLSA record generator to generate the TLSA record, for example https://www.huque.com/bin/gen_tlsa. In the generator, choose usage=3 (DANE-EE) and match=1 (SHA2-256). Note: it is safe to upload a certificate file to an online calculator, certificate files do not contain any secrets. Never upload a private key!

DANE/TLSA support in Mailhardener

Mailhardener has now fully integrated DANE/TLSA support in the Mailhardener Dashboard application.

Mailhardener customers can use Mailhardener to monitor the TLSA status of their inbound email, as well as using SMTP TLS reporting to monitor for TLSA failures.

Mailhardener also offers a free to use DANE/TLSA validator tool.

Conclusion

DANE is an ambitious protocol originally aimed to replace the PKI by moving the chain-of-trust to DNSSEC. DANE has been subject to critique from security professionals, as DNSSEC is said to lack robustness and cryptographic strength.

Fortunately, DANE can also be used to augment, rather than replace, the PKI in the form of certificate pinning via the TLSA DNS record. Certificate pinning can be an effective email hardening technique for SMTP services to protect against man-in-the-middle and (to a certain extent) TLS downgrade attacks.

Tools

• DANE/TLSA validator

Further reading

• How to create a DANE TLSA record with OpenSSL
• MTA-STS
• SMTP TLS reporting
• Microsoft releases DANE support