On Mon, Sep 25, 2023 at 08:46:48PM +0200, Erwin Hoffmann wrote:

one of my s/qmail users has problems with the TLSA/DANE record for the following domain:

• excalibur.iks-jena.de

That's the MX host of "iks-jena.de". For which the DANE survey:

https://stats.dnssec-tools.org/

shows no issues with the TLSA records vis-à-vis the corresponding certificate chains:

https://stats.dnssec-tools.org/explore/?iks-jena.de

The only issue with the domain is its use of the deprecated DNSSEC algorithm RSASHA1(5) (more on this further below).

Here, I get the settings:

$ dnstlsa excalibur.iks-jena.de Usage: [2], Selector: [1], Type: [1] 10f34e8f08e446cc26d7d591184b51cb83791c869cef388be5d5cb58e2927f7a Usage: [2], Selector: [1], Type: [1] 3c9762932ec8e6e52d4b37504f15d90a3fac9930e1058170372b3a4b0e068a43

where the root FP is ok, the MTA's not.

The TLSA RRset designates two DANE-TA(2) trust anchors, the first of which is the one currently in use, the second recently retired:

1. subject=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2023, emailAddress = ca@iks-jena.de issuer=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2023, emailAddress = ca@iks-jena.de notBefore=Dec 28 13:41:37 2022 GMT notAfter=Jan 26 13:41:37 2025 GMT

2. subject=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2022, emailAddress = ca@iks-jena.de issuer=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2022, emailAddress = ca@iks-jena.de notBefore=Jan 3 14:41:25 2022 GMT notAfter=Feb 2 14:41:25 2024 GMT

Per all relevant DANE specifications, it is sufficient for either to match the certificate chain.

Given the remarks in RFC 7672 section 3.1.2, I feel a bit uncomfortable about it.

If the qmail DANE implementation in question has problems with this domain, the problem is with qmail, not the DANE TLSA records or presented certificates.

On Mon, Sep 25, 2023 at 09:19:39PM +0200, Lutz Donnerhacke wrote:

...

• excalibur.iks-jena.de

As the admin of the server in question. What's the problem?

As noted above, nothing wrong with DANE. A DNSSEC algorithm rollover would however be prudent. Many RedHat systems no longer support the SHA1 DNSSEC algorithms 5 and 7 and your domain is "insecure" for validating resolvers running on these systems.

On Mon, Sep 25, 2023 at 11:02:53PM +0200, Erwin Hoffmann wrote:

Thanks for you remarks. There is still room for improvement.

When you say "room for improvement", are you talking about the DNSSEC algorithm? Or something else?

I'll have an eye on it. Talked to Lutz.

Were you able to identify what it was that qmail objected to? And what was the nature of the problem reported by qmail anyway?

Perhaps qmail simply does not support DANE-TA(2) records (considers them "unusable"), in which case it would presumably treat the domain as though DANE was not deployed.

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...

Lutz, maybe you could shed some light on this issue?

Indeed, for the record:

We do run a rolling CA, hence the CA keys are valid for two years and are used only for new certificates during the first year. Hence there are always two active CAs: One for certs issued in the current year, and one for still valid certs issued last year.

Of course we need to have appropriate TLSA records for each active CA. Of course, only one of the records can match for a validation. During the yearly rollover you may even see three such records for several weeks.

HTH

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).

On Tue, Sep 26, 2023 at 09:43:25AM +0200, Bjørn Mork wrote:

Viktor Dukhovni ietf-dane@dukhovni.org writes:

...

Many RedHat systems no longer support the SHA1 DNSSEC algorithms 5 and 7 and your domain is "insecure" for validating resolvers running on these systems.

This was a Redhat specific bug affecting validating resolver operations. It should be fixed by https://access.redhat.com/errata/RHBA-2022:8279

The "fix" was to treat algorithms 5 and 7 as unsupported, and the corresponding zones as unsigned. The behaviour before the fix was validation failure with the domain treated as "bogus".

RSASHA1 validation is not optional. It's still a MUST: https://datatracker.ietf.org/doc/html/rfc8624#section-3.1

That is somewhat dated (predates https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html), and is in any case ignored by RedHat.

(and anyone who believe that's wrong should work to update the standard, not violate it. You'd think players like Redhat knew that)

You'd think, but they did what they did. And regardless, the algorithm rollover is still overdue.