🪲: DANE TLSA support looks far from correct

[vdukhovni]

What happened?

A quick read of the code suggests the following defects:

• When TLSA records include both the DANE-EE(3) usage and DANE-TA(2), it appears that BOTH must match
  • That is, if no usage DANE-EE(3) records match, the DANE-TA(2) records are not considered
  • When only DANE-TA(2) records are published, the chain is verified using WebPKI trust anchors, and then required to match one of the DANE-TA(2) records, which is PKIX-TA(0) semantics, not DANE-TA(2).
  • It is unclear how TLSA base domain is determined, when DANE is in effect, the TLSA base domain should be used as the SNI hostname and should also be the hostname checked when verifying DANE-TA(2) chains, which need not be anchored at a WebPKI CA, so DANE-TA(2) verification needs to override the trust-anchors to enable anchoring the chain at a possibly non-self-signed (subsidiary/intermediate) CA, or a private root, or a WebPKI root, ... And the TA is almost always in the form of a hash, so the verification logic is custom code, distinct from the standard PKIX logic.
  • When both DANE-EE and DANE-TA records are published, the TLSA base domain is ignored for matching the EE cert, but MUST be verified when matching issuer certs.
    • A strictly correct implementation would also allow the nexthop (typically recipient) domain to match if TLSA base domain does not. And also the MX hostname if distinct from the TLSA base domain (when that is found by CNAME chasing).

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

Version

v0.13.x

What database are you using?

None

What blob storage are you using?

None

Where is your directory located?

None

What operating system are you using?

None

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

Stalwarts generates all possible TLSA records, you need to choose the ones that make sense for your deployment.

[vdukhovni]

This is not a substantive response to the bug report. Stalwarts handling of outbound DANE as a client is incorrect.
You don't get to choose the remote MX host's TLSA records, instead, validation of these needs to be implemented correctly.

[mdecimus]

Sorry, I didn't read the description in detail and assumed it was yet another bug report related to TLSA DNS records generated by Stalwart.
It's been a while since I've implemented DANE so I'll have to go back to the specs and check your report in more detail.

[m4b]

I don't have a pony in this race, so to speak, but as a user of stalwart for my personal email (thanks!),, I am a little confused what I'm supposed to do with the DNS record/zonefile that is generated when I click "show DNS record". On the one hand, it seems like I'm supposed to copy all of the zonefile and update my DNS record with it, but on the other, given the response above, it sounds like I should not choose every line for the TLSA records, if i understood correctly? It would be nice at least to get some clarification on this, or if there is a best practices here, to have zonefile generation have an option to generate a "sensible defaults"

For reference, I'll just paste the current output of my zonefile right now:

@                  IN MX    10 mail.m4b.io.
202507e._domainkey IN TXT   "v=DKIM1; k=ed25519; h=sha256; p=VeoOh3eSpvJj5PlTwqOGFpEiZunPNERUIJ+XjFeUpbs="
202507r._domainkey IN TXT   "v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0/ErcjEyWe7PcbtJAHI58xjo9paPHXIYzskLHYMPQ03veklIHNohjUZFg6ds1PCfi8F2pf9D4LHd8GtuFSUpLvEACT3zgA+acwIGP5zt8nO1y3s3E5mOLleKnZS/jt8Rl6kT0s7U8q6F9nqy6I3Itq1N9BwTuBxPb8OOdGcebbpOBgfJaoajl7" "oigSbAla9eSx+My42nofQqDMwmcwkJ+DA2TAO7yqZuQegtBvK7mqEUAP+QaoRt8RS4BJibRePyo0F1mnmmnZszaAJ5lxF4bAcgjoHvWrXxbC86sNB69slFNgfaLyfPuVnfC/05VkTXrn6kDTip5otboxzRcVnnQIDAQAB"
mail               IN TXT   "v=spf1 a ra=postmaster -all"
@                  IN TXT   "v=spf1 mx ra=postmaster -all"
_jmap._tcp         IN SRV   0 1 443 mail.m4b.io.
_caldavs._tcp      IN SRV   0 1 443 mail.m4b.io.
_carddavs._tcp     IN SRV   0 1 443 mail.m4b.io.
_imaps._tcp        IN SRV   0 1 993 mail.m4b.io.
_submissions._tcp  IN SRV   0 1 465 mail.m4b.io.
_submission._tcp   IN SRV   0 1 587 mail.m4b.io.
autoconfig         IN CNAME mail.m4b.io.
autodiscover       IN CNAME mail.m4b.io.
mta-sts            IN CNAME mail.m4b.io.
_mta-sts           IN TXT   "v=STSv1; id=7346520781178448425"
_dmarc             IN TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]"
_smtp._tls         IN TXT   "v=TLSRPTv1; rua=mailto:[email protected]"
_25._tcp           IN TLSA  3 0 1 ad717482dd210034d050490a130f35be754a26719714de27e8ab6cc12d2d4c05
_25._tcp           IN TLSA  3 0 2 5fb5fd6afe4d6b4d7c04e4888f4b59f686d10aefbe7c40f69dd0569a2d17ebf74258624eda1d51d129c7ba07ef4892380438aa652e17b78f05c13ccaa075a5a0
_25._tcp           IN TLSA  3 1 1 232886ebfe85312fb213a8c3f3f3f716be6f325b25b3328dece5bfba76455ea7
_25._tcp           IN TLSA  3 1 2 c455ae721eb5d13ee3a1f2a4851f238a82ca2652a3cedeadb20455d5edae2a9a07b2c098fc5b659412db760f098f81ce8db98d7013fa51eead8865d1581e22a1
_25._tcp           IN TLSA  2 0 1 131fce7784016899a5a00203a9efc80f18ebbd75580717edc1553580930836ec
_25._tcp           IN TLSA  2 0 2 a49a194c435cb8398246276d22d30f840080030025f3564f5feae43a0e6327268b37ea5e24eff31d77f0f1fd605c22ad0c346c71a003b31cdc723a5b12218569
_25._tcp           IN TLSA  2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
_25._tcp           IN TLSA  2 1 2 661ba3b2ba5c26c64cfca723320b98984ae813d89ec8a6a0d4845d850197c2fa00add80db09b4785d8bd1ecfc518ee4ad6d0989a48e1325bfc1a99208e23538e
_25._tcp.mail      IN TLSA  3 0 1 ad717482dd210034d050490a130f35be754a26719714de27e8ab6cc12d2d4c05
_25._tcp.mail      IN TLSA  3 0 2 5fb5fd6afe4d6b4d7c04e4888f4b59f686d10aefbe7c40f69dd0569a2d17ebf74258624eda1d51d129c7ba07ef4892380438aa652e17b78f05c13ccaa075a5a0
_25._tcp.mail      IN TLSA  3 1 1 232886ebfe85312fb213a8c3f3f3f716be6f325b25b3328dece5bfba76455ea7
_25._tcp.mail      IN TLSA  3 1 2 c455ae721eb5d13ee3a1f2a4851f238a82ca2652a3cedeadb20455d5edae2a9a07b2c098fc5b659412db760f098f81ce8db98d7013fa51eead8865d1581e22a1
_25._tcp.mail      IN TLSA  2 0 1 131fce7784016899a5a00203a9efc80f18ebbd75580717edc1553580930836ec
_25._tcp.mail      IN TLSA  2 0 2 a49a194c435cb8398246276d22d30f840080030025f3564f5feae43a0e6327268b37ea5e24eff31d77f0f1fd605c22ad0c346c71a003b31cdc723a5b12218569
_25._tcp.mail      IN TLSA  2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
_25._tcp.mail      IN TLSA  2 1 2 661ba3b2ba5c26c64cfca723320b98984ae813d89ec8a6a0d4845d850197c2fa00add80db09b4785d8bd1ecfc518ee4ad6d0989a48e1325bfc1a99208e23538e

I'm not an email expert by any means, just dipping my feet in (again thank you for the excellent software and great configuration story!), but it would be nice to know if in general I should only choose a subset of the TLSA lines, and maybe communicate that in either a info popup in the admin console, a comment (I don't think zonefiles support comments :/ ), or perhaps a different option to generate a default that uses sensible defaults for TLSA, or lastly update the documentation to note this important detail if we shouldn't use every line.

Today currently, I believe the documentation suggests to copy the zonefile wholesale to your DNS records, which sounds like it might not be totally correct to do so?

[vdukhovni]

My bug report concerns stalwart as SMTP client, consuming (and failing to correctly validate) TLSA records published by remote servers. Your question above is about what records to publish as an SMTP server. That's a separate topic. The quick answer is that best current practice is "3 1 1 + 3 1 1", which means:

• One or more "3 1 1" records matching the current key(s) (if server has keys/certs for multiple algorithms, for experts only).
• One or more "3 1 1" record for the next key(s), published a few DNS TTLs before they're deployed with the corresponding certs.
• If you're rolling over the cert, and later updating the DNS you're doing it wrong.
• TLSA records matching previously current keys can be dropped as soon as keys are no longer live, and the next keys have been deployed and taken their place.

[vdukhovni]

Ignore all the redundant records with selector "0" or matching type other than 1. You can publish 2 1 1 records, if you're willing to trade off security for somewhat more stable intermediate issuer keys, but see: https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

[pepa65]

Thank you for answering this OT question in such a clear way! Deserves to be in the FAQ or other part of the documentation.

[vdukhovni]

Thank you for answering this OT question in such a clear way! Deserves to be in the FAQ or other part of the documentation.

You're welcome, my recommendation remains "3 1 1", but I should have mentioned that with DANE TLSA deployment MONITORING is not optional. Before publishing TLSA records for your MX hosts, implement monitoring that would generate a timely alert if any of the IP addresses of any of the MX hosts present a certificate chain that fails to match the TLSA records. Check at least hourly, and make sure that alerts would get through even if the TLSA records are invalid. Only then publish TLSA records, and automate certificate rollover in a manner that ensures that matching TLSA records are prepublished before any new keys go live.

The DANE survey at https://stats.dnssec-tools.org/ has been taking up some of the slack for years, but it ls never sufficiently timely, at best you learn about problems a day or more later, and not everyone has working+discoverable notification email addresses.

[mdecimus]

Reopened #2328