On Sat, Jun 15, 2024 at 09:28:37PM +0200, Erwin Hoffmann wrote: > > If you use "nolisting" and use DANE, you should make sure to have > > syntactically correct TLSA records for the nolisting MX hosts, which > > ideally don't match any other existing cert. This is what > > ns1.samba.org has: > > > > # host -t TLSA _25._tcp.ns1.samba.org > > _25._tcp.ns1.samba.org has TLSA record 3 0 1 > > 00000000000000000000000000000000000000000000000000000000 00000000 > > could you point me to a RFC, where this is specified?
If one of a domain's MX hosts has no TLSA records, email to the domain is subject to active attacks even if all the primary and/or various other MX hosts do have TLSA records. An on-path attacker can block connections to all the protected MX hosts, and intercept the connection to the unprotected one. https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.3 If the ultimate response is a "secure" TLSA RRset, then the candidate TLSA base domain will be the actual TLSA base domain, and the TLSA RRset will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records, then the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext). > I don't think that neither 'nolisting' nor publishing a 'nullified' > TLSA recored is a good idea. Indeed "nolisting", though mostly harmless, and perhaps helpful to reduce abuse in some cases, is not a best practice. On the other hand, publishing a TLSA record matching nothing, even for inactive MX hosts is, in fact, required in order to avoid downgrade attacks. -- Viktor.
