Repository files navigation

Use DANE to start and verify secure SMTP connections between MTAs (or MUA-to-MTA submission). This mitigates a MITM-attack.

• Your mail serversupports STARTTLS.
• Your domain (and mail server domain) are usingDNSSEC.

👉 DANE for email you receive =publishing a DNS record.

• Your mail server has support for DANE.

👉 DANE for email you send =configuring your mailserver.

DANE first looks up the TLSA-records in the DNS. When one or more valid records are found: The mailserver will start a TLS connection.Opening that connection returns a certificate. That certificate must match one of those TLSA-records.

The FQDN in theMX-record is used to connect with TLS on TCP port 25.

With a TLSA record in your DNS; A server that wants to send to you can verify the certificate that it receives.

👉 You probably want to use: DANE-EE(3), SPKI(1), SHA-256(1):

_25._tcp.server.example.com. 300 IN TLSA 3 1 1 <your SHA2-256 hash>

Replace the value of<your SHA2-256 hash> with thehashed value of your own certificate.
Replaceserver.example.com with your own (sub)domain.

• Mailservers on the same domain (one.server.com, two.server.com) need a TLSA record for each of their subdomains.
• Mailservers on a different domain (mailserver.com, backup-server.com) both need a TLSA record in their own zone.
• Beware of servers that use SNI: Add two TLSA-records when the server in the MX-record is not using the default certificate.

The DNS-record consists of the following 4 fields:

• PKIX-TA(0)
• PKIX-EE(1)
• DANE-TA(2) Trust Anchor — Root or Intermediate Certificate
• DANE-EE(3) End Entity Certificate

DoNOT use PKIX-TA(0) and PKIX-EE(1).Postfix discards those records.Exim seems to support PKIX but there isno added security when an application supports all four certificate usages. You only need more DNS-records and possibly run into the issue of a mail server (sending to you)not having that root or intermediate.

The use of a public authority e.g: "Let's Encrypt" with DANE-TA(2) records opens you up tovarious risks of certificate mis-issuance, because Let's Encryptoperates on a TOFU (trust on first use) model, with rather weakproofs of domain control. Some users are willing to accept this risk for the convenience of usingLet's Encrypt, enabling a single certificate to support both MTA-to-MTASMTP and MUA-to-MTA submission, ... Others prefer to avoid the security risks.Google have their own dedicated intermediate CA, they can use aDANE-TA(2) record for that CA without much risk. A company witha corporate account with a CA and managed enrollment (no TOFU)might do likewise.
— by Viktor Dukhovni (May 03, 2022)

👉 Prefer DANE-EE(3). Consider DANE-TA(2) when you are that Root or Intermediate.

• Cert(0) Full Certificate
• SPKI(1) Subject Public Key Info

TLSA Publishers employing DANE-TA(2) records SHOULD publish records witha selector of "Cert(0)". Otherwise SPKI(1) is recommended because itis compatible with raw public keys [RFC7250] and the resulting TLSArecord needs no change across certificate renewals when issued with the same key.

👉 Use SPKI(1) with DANE-EE(3). Use Cert(0) with DANE-TA(2).

• Full(0)
• SHA-256(1) SHA2-256 hash
• SHA-512(2) SHA2-512 hash

Always use SHA-256(1). DoNOT use type Full(0).In the future you want to useboth of these hashes.When SHA2-512 (and any upcoming algorithms) become mandatory for applications to implement (as defined in future RFCs). Then you would be using those mandatory algorithm(s) only.

👉 Use SHA-256 for now. Care about SHA-512 later.

Contains the value of the Certificate or Public Key. In this case the SHA2-256 hash of the Cert(0) or SPKI(1).

$ dig +short MX"example.com"

As an example we state that the command above returns the following result:

10 your-mail-server.com.11 your-backup-mail-server.com.

In this case you want to run the openssl commands (explained below) to verify the certificates you receive (for both of these servers).Then you want to add a TLSA record for each of these servers in their own zone.

$ openssl s_client -connect"your-mail-server.com:25" -starttls smtp</dev/null

The command above prints the certificate that is being used.When using DANE-TA(2) you need to make sure that you send that Trust Anchor as well (you would be sending the full chain in stead of a single certificate). Otherwise there is no value (cfr. certificate) to compare. Therefor verification will never pass.

$ openssl s_client -connect"your-mail-server.com:25" -starttls smtp -servername"mail.example.com"</dev/null

When the certificate is different in the two commands above: Make sure you add a TLSA record for both certificates. Servers that do not support SNI will receive the certificate from the first openssl command (because it is the fallback certificate).

Prefer using the hostname of the IPv4 (the reverse DNS). In this case all servers (with or without SNI) should receive the same certificate.You can verify this by running the two openssl commands above. In this case they must return the same certificate.

In the openssl commands above: Most cases will return a single certificate.That would be yourEnd Entity certificate (DANE-EE).You want to manually verify that the certificate you received is the same as the one you are using on your server.

echo$(openssl x509 -in"/path/to/cert.pem" -noout -pubkey \| openssl pkey -pubin -outform DER \| openssl sha256 -binary \| hexdump -ve'/1 "%02x"')

In the command above, replace/path/to/cert.pem with the location of your servers end certificate.

DANE-TA(2)should use the "Full certificate(0)" selector in stead of the "SPKI(1)". Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. Otherwise this may, for example, allow a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.

echo$(openssl x509 -in"/path/to/ca.pem" -outform DER \| openssl sha256 -binary \| hexdump -ve'/1 "%02x"')

In the command above, replace/path/to/ca.pem with the location of your root or intermediate certificate.

The recommended: DANE-EE(3) with SPKI(1) and SHA256(1) would result in a DNS-record e.g:

_25._tcp.your-mail-server.com. IN TLSA 3 1 1 <sha256-hash>

And optionally a DNS-record for the backup server:

_25._tcp.your-backup-mail-server.com. IN TLSA 3 1 1 <sha256-hash>

DANE-TA(2) with FullCert(0) and SHA256(1) would result in a DNS-record:

_25._tcp.your-mail-server.com. IN TLSA 2 0 1 <sha256-hash>

DANE-TA(2) withDigest Algorithm Agility would result in two DNS-records:

_25._tcp.your-mail-server.com. IN TLSA 2 0 1 <sha256-hash>_25._tcp.your-mail-server.com. IN TLSA 2 0 2 <sha512-hash>

Consider the use of Digest Algorithm Agility when SHA2-256 becomes weak.

Email that you send, will search for the TLSA records of the receivers MX-domain. When a record is found, your server will start a TLS connection and verify the certificate it receives.

• Configuring Postfix mailserver
• Configuring Exim mailserver

$ bash validate-dane-tlsa.sh"example.com"

$ bash dane-tlsa.sh"/path/to/cert.pem"

https://datatracker.ietf.org/doc/html/rfc7671#section-8.1

Sources:

• RFC6698
• RFC7218
• RFC7671
• RFC7672
• https://mecsa.jrc.ec.europa.eu/en/technical#dane
• https://github.com/internetstandards/toolbox-wiki/