Hi Viktor, thanks for you remarks. There is still room for improvement.
I'll have an eye on it. Talked to Lutz. Regards. --eh. Am Montag, dem 25.09.2023 um 15:52 -0400 schrieb Viktor Dukhovni: > 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 = > [email protected] > issuer=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU > = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2023, emailAddress = > [email protected] 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 = > [email protected] > issuer=C = DE, ST = Thuringia, L = Jena, O = IKS Service GmbH, OU > = IKS CA, CN = CA der IKS Service GmbH (SIGN) 2022, emailAddress = > [email protected] > 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. > -- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 20FD6E671A94DC1E PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
signature.asc
Description: This is a digitally signed message part
