On Wed, Sep 27, 2023 at 10:30:27AM +0200, Erwin Hoffmann wrote:
Though perhaps regrettable, such minimal DANE implementations (that support only DANE-EE(3)) are not unheard of. That's fine, mail should still be delivered...
Actually, publishing DANE- TA(2) fingerprints without considering the MTA's cert (as Lutz explained) was not considered in my (as you say correctly: minmal) approach.
In the forthcoming version of s/qmail (note: s/qmail is not qmail), I'll will do FP tests on the entire cert chain, in order to cope with this case.
Note that I sadly encountered more than one past "naïve" effort to implement support for DANE-TA(2) which turned to have various serious gaps, making the promised security illusory. It's probably best if you don't attempt to do the chain validation yourself, and delegate the work to OpenSSL's built-in support for DANE.
This is for example the approach in the most recent releases of Postfix (though as a matter of historical accuracy, DANE came to Postfix first, and OpenSSL only some years later, and then it took a few years to replace the DANE support in Postfix with calls to OpenSSL).
Avoid DYI. You'll get support for both DANE-EE(3) and DANE-TA(2) for free. All you have to do is obtain DNSSEC-signed TLSA records in a downgrade-resistant manner as described in RFC7672 and "feed" them into OpenSSL to set up connection security (also of course refuse to use cleartext for MX hosts TLSA records).