Petr Menšík <[email protected]> writes:
> Now what is the instruction about validation in this case? If the
> crypto library does not allow validation of any RSA1 signature, it
> will just fail. That is case of DEFAULT crypto-policy on RHEL 9 and
> 10. Similar behaviour can be configured on Fedora DEFAULT:NO-SHA1
> crypto policy.
Correct, the document states that people really really really need to
stop using SHA1 on the publication side ("MUST NOT be used when
creating..."), but really should still allow them to be validated as the
world has not yet shifted away from following the "MUST NOT be used when
creating..." guidance. Yet. Since there are at least still 100k+
domains still signing with them [1].
[1] https://stats.dnssec-tools.org/#/?top=parameters&dnssec_param_tab=0
>
> In this case, resolver is not able to validate RSASHA1 even with the
> best intent. The only way around is to bundle own crypto library,
> which does not block validation of SHA1 signatures. Is that what is
> recommended here?
>
> More specific:
>
> Validating
> resolver implementations ([RFC9499], Section 10) MUST continue to
> support validation using these algorithms as they are diminishing in
> use but still actively in use for some domains as of this
> publication.
>
> We have no way to implement this on RHEL. We would like MUST changed
> to SHOULD in this sentence. Is it possible as part of errata?
>
> I think it goes directly against section 5:
>
> Alg 1:
> Use for DNSSEC Validation: RECOMMENDED
>
> Alg 5:
> Use for DNSSEC Validation: RECOMMENDED
>
> Alg 7:
> Use for DNSSEC Validation: RECOMMENDED
>
> Now, how is it possible to be RECOMMENDED, when it is also a MUST in
> section 2?
>
> Can you clarify how is it meant?
>
> I am sorry this was noticed only after final publication. But except
> it clearly say to not create new alg 5 or 7 signatures, I am not sure
> what is instruction for receiving them.
>
> On 01/12/2025 01:35, [email protected] wrote:
> > A new Request for Comments is now available in online RFC libraries.
> >
> > RFC 9905
> >
> > Title: Deprecating the Use of SHA-1
> > in DNSSEC Signature Algorithms
> > Author: W. Hardaker,
> > W. Kumari
> > Status: Standards Track
> > Stream: IETF
> > Date: November 2025
> > Mailbox: [email protected],
> > [email protected]
> > Pages: 5
> > Updates: RFC 4034, RFC 5155
> >
> > I-D Tag: draft-ietf-dnsop-must-not-sha1-10.txt
> >
> > URL: https://www.rfc-editor.org/info/rfc9905
> >
> > DOI: 10.17487/RFC9905
> >
> > This document deprecates the use of the RSASHA1 and
> > RSASHA1-NSEC3-SHA1 algorithms for the creation of DNS Public Key
> > (DNSKEY) and Resource Record Signature (RRSIG) records.
> >
> > It updates RFCs 4034 and 5155 as it deprecates the use of these
> > algorithms.
> >
> > This document is a product of the Domain Name System Operations Working
> > Group of the IETF.
> >
> > This is now a Proposed Standard.
> >
> > STANDARDS TRACK: This document specifies an Internet Standards Track
> > protocol for the Internet community, and requests discussion and suggestions
> > for improvements. Please refer to the current edition of the Official
> > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
> > standardization state and status of this protocol. Distribution of this
> > memo is unlimited.
> >
> > This announcement is sent to the IETF-Announce and rfc-dist lists.
> > To subscribe or unsubscribe, see
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> >
> > For searching the RFC series, see https://www.rfc-editor.org/search
> > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> >
> > Requests for special distribution should be addressed to either the
> > author of the RFC in question, or to [email protected]. Unless
> > specifically noted otherwise on the RFC itself, all RFCs are for
> > unlimited distribution.
> >
> >
> > The RFC Editor Team
> >
> >
> > _______________________________________________
> > DNSOP mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
--
Wes Hardaker
Google
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
