This went unanswered, so let me. > We have no way to implement this on RHEL.
Shrug. The RFC is a result of a working group consensus. RedHat made a choice for RHEL, and I see no reason why the RFC should change to make RHEL compatible. The other options might be for RHEL to actually follow the RFC or RHEL can choose to **not** be standards compliant. RHEL made a choice about SHA-1 and now it has to live with it. > We would like MUST changed to SHOULD in this sentence. Is it possible as part > of errata? No, this is definitely not something for errata, see: https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ > Errata are items that were errors at the time the document was published -- > things that were missed during the last call, approval, and publication > process. If new information, new capabilities, or new thinking has come up > since publication, or if you disagree with the content of the RFC, that is > not material for an errata report. Such items are better brought to relevant > working groups, technical area discussions, or the IESG. Ondrej -- Ondřej Surý (He/Him) [email protected] > On 1. 12. 2025, at 14:00, Petr Menšík <[email protected]> > wrote: > > Hello! Our crypto folks are truly confused in wording of paragraph 2 of this > document. > > I admit I am not sure myself, what the instruction is in this paragraph: > > The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms > MUST NOT be used when creating DNSKEY and RRSIG records. 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. Operators of validating resolvers MUST treat DNSSEC > signing algorithms RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, > rendering responses insecure if they cannot be validated by other > supported signing algorithms. > > 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. > > 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] > > -- > Petr Menšík > Senior Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
