Sebastian: Created page with "Category:Deliverability Category:Authentication 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-bas..."

2025-08-15T13:46:45Z

Created page with "Category:Deliverability Category:Authentication 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-bas..."

New page

[[Category:Deliverability]]
[[Category:Authentication]]

In modern E-Mail communication, [[wikipedia:Opportunistic_TLS|Opportunistic TLS]] is common. This means that [[wikipedia:Transport_Layer_Security|TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s 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 [https://www.rfc-editor.org/rfc/rfc6698 RFC 6698]. It's main purpose is to secure TLS connections against [[wikipedia:Man-in-the-middle_attack|MitM (Man in the Middle) attacks]]. Dane requires [[wikipedia:DNSSEC|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:

# Querying MX records from the '''recipient domain'''.
# 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:

<pre>
$ host -t tlsa _25._tcp.mta.example.com
</pre>

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.

{| class="wikitable"
|+ 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.

{| class="wikitable"
|+ 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.

{| class="wikitable"
|+ 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:

<pre>
_25._tcp.mta.example.com has TLSA record 3 1 1 0AD1234567890ABCD1234567890ABCD1234567890ABCD1234567890ABCD12390
</pre>

==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]]

[https://www.rfc-editor.org/rfc/rfc8460 RFC 8460] states that <q>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.</q> Even though this is not explicitly mentioned in RFC 6698, DANE compliant MTAs should be able to receive and process TLSRPT reports.

=Useful links=

* [https://tools.ietf.org/html/rfc8460 RFC 8460]: TLSRPT RFC
* [https://tools.ietf.org/html/rfc6698 RFC 6698]: DANE RFC
* [https://inboxsys.com/dmarc-monitor/ InboxSys DMARC Monitor]
* [[wikipedia:DNSSEC]]
* [[wikipedia:Opportunistic_TLS]]

DNS-based Authentication of Named Entities (DANE) - Revision history