DNS-based Authentication of Named Entities (DANE)

In modern E-Mail communication, Opportunistic TLS is common. This means that TLS encryption for the transition of E-Mail is negotiated by MTAs on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement can be reached, mail is transferred unencrypted.

DANE (DNS-based Authentication of Named Entities), together with the TLSA protocol, was introduced in RFC 6698. It's main purpose is to secure TLS connections against MitM (Man in the Middle) attacks. Dane requires DNSSEC. DANE compliant Mail is returned to the sender if the TLS negotiation fails.

Configuration and setup

DANE is set up on the recipient's mail host in multiple layers:

DNSSEC

The first connection attempt requires DNSSEC for all DNS queries:

1. Querying MX records from the recipient domain.
2. Querying MX domains / MTA hostnames for TLSA records.

TLSA DNS record

TLSA records are set on MTA hostnames on a sudomain that consists of:

• Port
• Protocol (UDP, TCP or SCTP)

For example, if the MTA has mta.example.com as hostname, TCP as protocol and we're using port 25 for SMTP connections, this is what a lookup of the TLSA record would look like:

$ host -t tlsa _25._tcp.mta.example.com

Inside the record, we find the following components:

Certificate Usage Field (CUF)

The CUF specifies how the recipient server's certificate is to be verified.

Certificate Usage Field

Value	Type	Description
0	PKIX-TA	Allows the certificate of the trust anchor to be utilised along with Certificate Authority certificates
1	PKIX-EE	PKIX verification, including various checks
2	DANE-TA2	Validate the domain TLS certificates using the server private key from the X.509 (PKI) tree
3	DANE-EE	The CUF must only match against the certificate

Selector Field (SF)

The SF specifies which part of the recipient server's TLS certificate will be matched against the Certificate Association Data.

Selector Field

Value	Type	Description
0	SubjectPublicKeyInfo (SPKI)	Parts of the certificate, such as public key, pk algorithm, etc.
1	Full certificate	Full certificate

Matching Type Field (MTF)

The MTF specifies how the CAD is presented for use with the Selector Field.

Matching Type Field

Value	Type	Description
1	SHA-256	SHA-256 hash of CAD based on the SF value
2	SHA-512	SHA-512 hash of CAD based on the SF value
0	Full	Exact match against CAD based on the SF value

Certificate Association Data (CAD)

At the end of the TLSA record, we find a long string named Certificate Association Data (CAD). This field contains the hashed certificate date that matches the CUF.

That said, the result of our above lookup could be something like this:

_25._tcp.mta.example.com has TLSA record 3 1 1 0AD1234567890ABCD1234567890ABCD1234567890ABCD1234567890ABCD12390

STARTTLS

STARTTLS is required on the recipients server for DANE to work. If no STARTTLS is offered, a so-called "downgrade attack" is suspected and the connection is dropped immediately. If STARTLS is offered, the checksum of the TLS certificate is compared to the information found in the TLSA DNS record.

TLS reporting

Main article: TLSRPT

RFC 8460 states that Recipient domains may also use the mechanisms defined by MTA-STS [RFC8461] or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains. Even though this is not explicitly mentioned in RFC 6698, DANE compliant MTAs should be able to receive and process TLSRPT reports.

Useful links

• RFC 8460: TLSRPT RFC
• RFC 6698: DANE RFC
• InboxSys DMARC Monitor
• wikipedia:DNSSEC
• wikipedia:Opportunistic_TLS