Hacker News new | ask | show | jobs
by mjl- 939 days ago
First, DANE requires that your DNS is protected with DNSSEC. Your MX records need to be DNSSEC-protected because otherwise any attacker that can give a sender fake MX records can cause an email message to be delivered to a mail server of their choice. The IP lookups to connect to your MX host needs to be DNSSEC-protected, and your TLSA records need to be DNSSEC-protected. For self-hosters, this is usually all the same domain.

Second, your MX host needs DNS records of type TLSA that specify the public keys that are in your TLS certificates that your MX host (mail server) offers during STARTTLS. This is the most common mode for DANE, called DANE-EE (EE = end entity). In this mode, only the public key of the certificate matters. Expiration, hostname match, issuing party of certificates: all ignored. If your MX target is mx.example.com, the TLSA record(s) must be under: _25._tcp.mx.example.com. They will look like this:

3 1 1 5c046ff012891b5f0d6176024c5c25ff486a7c12b8000fdf8b418ab3ecf6d309

3 1 1 cec87fb33d2a7499ca78e824e59b77531ac1fdec7378fc81fce7e5d213a364ab

In these records, "3 1 1" means:

Usage "dane-ee" (3), Selector "spki" (1), Matchtype "sha2-256" (1)

Where spki means "subject public key info", i.e. only the public key matters. So, the last component is the sha2-256 hash of the public key. A mail server can have multiple certificates (e.g. RSA and ECDSA). Each must have a TLSA record.

Keep in mind that when you renew your certificate, you could be reusing your private key or be generating a new private key. A new private key brings a new public key. A new public key requires an updated TLSA record. Keep in mind DNS TTLs in that case. You would have to keep both the old and new TLSA records during the TTL period. I would recommend you don't generate a new private key for each new certificate. If the private key stays the same, the TLSA records don't need to be changed.

MTA-STS requires that the MX host TLS certificate can be verified against the common pool of certificate authorities, i.e. PKIX/WebPKI. DANE and MTA-STS can cooexist. I would recommend setting up both DANE and MTA-STS, using ACME with Let's Encrypt with fixed private keys (not newly generated when fetching a new certificate, I know certbot has an option for this mode), and publishing TLSA records (with the hashes of the public keys of those fixed private keys).

Keep in mind some sending mail servers only implement DANE, and others only MTA-STS. Implementing both gets most protection. Some mail servers implement neither, and are sending email without protection.

1 comments

> The IP lookups to connect to your MX host needs to be DNSSEC-protected

Really? It does not seem necessary to require this. I mean, the security is guaranteed by the public keys in the TLSA records, right? Yes, the MX lookup and the TLSA lookups must be DNSSEC signed, but does DANE actually require the A/AAAA lookup of the server name in the MX record to also be DNSSEC signed? It does not seem necessary from a security standpoint.

You are correct that it is not needed for security. It is also not required for plain DANE. But it is for DANE for SMTP. The reason is interoperability.

Apparently, some DNS servers would not respond at all to requests for TLSA records (probably fixed in the software by now, but some infra may still run old software). If a sending mail server would request TLSA records, not receive a response, it would have to assume DANE _may_ be required, and abort the delivery attempt. This would lead to mail being undeliverable due to those old DNS servers. Such old DNS servers probably wouldn't be set up for DNSSEC, and with this workaround, the TLSA records wouldn't be requested, so there would be no lookup failure that blocks delivery.

See the paragraphs after the enumeration in https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.2

Oh, right. Thanks for explaining!