Index

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).

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 is specified in rfc7671. The TLSA resource record is specified in rfc6698.

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

For email, DANE can be used to perform certificate pinning on the inbound mail exchange (MX) services. This helps ensure that senders cannot be tricked into delivering email to a rogue email service (known as a man-in-the-middle attack). Depending on how the sending service is set up, DANE can also help against downgrade attacks.

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:

rfc8460 failure description
tlsa-invalid None of the TLSA records matched the certificate of the SMTP service.
dnssec-invalid This indicates that the recursive resolver was not returning any valid DNSSEC signed record
dane-required This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report.

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.

screenshot showing SMTP TLS report with a DANE related error in the Mailhardener dashboard
Example of an SMTP TLS report with a DANE error in the Mailhardener dashboard

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.

DANE MTA-STS
Trust source DNSSEC root keys PKI Certificate Authority
Mechanism DNS HTTPS (DNS bootstrap)
Certificate pinning Yes No
PKI Optional (but recommended) Required
Certificate revocation Possible Not possible

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:

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.

value rfc7671 name description
0 PKIX-TA PKI 'trust anchor' (CA root certificates)
1 PKIX-EE PKI 'end entity' (a certificate issued by a trusted CA)
2 DANE-TA DANE 'trust anchor' (self-signed root certificate)
3 DANE-EE DANE 'end entity' (domain issued or self-signed certificate)

For SMTP usage, the typical certificate is issued by a trusted PKI CA, so usage type 1 will be used.

Selector field

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

value certificate part description
0 Full certificate The entire DER encoded certificate is used
1 SubjectPublicKeyInfo Only the DER encoded public key of the certificate is used

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.

value certificate part
0 Exact match
1 SHA2-256 hash digest
2 SHA2-512 hash digest

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 1 0 1 (E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )

We can decode this record as follows:

property value
port 25
protocol tcp
host mail.example.com
DNS rr type TLSA
TLSA usage PKIX-EE (1)
TLSA selector full certificate (0)
TLSA match SHA2-256 (1)
TLSA certificate association data E8B54E0B4BAA815B06D3462D65FBC7C0CF556ECCF9F5303EBFBB77D022F834C0

Meaning that:

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:

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

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

selector benefit consequence
0 (full certificate) allows for effective revocation of a certificate TLSA must be renewed with each certificate renewal
1 (SubjectPublicKeyInfo) TLSA record requires no renewal on certificate renewal (unless key is changed) TLSA record renewal may be forgotten on eventual key rotation

Step 2: Use a TLSA record generator to generate the TLSA record, for example https://www.huque.com/bin/gen_tlsa Choose usage=1 (PKIX-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.

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.

screenshot showing example domain with DANE support
Example of an domain with DANE/TLSA enabled in the Mailhardener dashboard

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

Further reading

Share your thoughts!

On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.

You can also follow and reach us on Twitter @Mailhardener.

With Mailhardener you can configure, validate and monitor your domain for all aspects of email security. Mailhardener is free to use for a single domain.
Sign up now