Wearing my "pedantic vocabulary enforcer" hat, I am happy that we have paths forward but very concerned about the specific wording in those paths. The WG was clear in its wording, and this clarity should be exhibited in the final RFC.
On Aug 13, 2025, at 09:57, Wes Hardaker <[email protected]> wrote: > Background: as specified in draft-ietf-dnsop-rfc8624-bis, the goal of > algorithm update documents like the draft-ietf-dnsop-must-not-sha1 document > should clearly differentiate between whether a requirement is targeting > implementations or the deployments (operators). Both of these documents are > currently in the RFC Editors queue, and as such the authors believe they > should be changed as minimally as possible in order to fix any current > misunderstandings. The point behind the draft-ietf-dnsop-must-not-sha1 > document was to recommend that all deployment of SHA1 algorithms in DNSSEC > stop.. But, because there is an existing sizable deployment level, that > implementations should continue to provide implementation of the algorithms > even if their defaults were to use a different set of algorithms. Basically, > if an operator feels that they really need to still support SHA-1, the > software that they use needs to still have it available within the > implementation. The current version of draft-ietf-dnsop-must-not-sha1 says: The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms MUST NOT be used when creating DS records. Validating resolvers MUST treat RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure. . . . 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. Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero use, deployed validating resolvers MAY be configured to continue to validate RRSIG records that use these algorithms. Those are five statements: 1) zone owners must not create new DS records with those algorithms 2) resolver operators must treat chains that contain such DS records as insecure 3) zone owners must use DNSKEY or RRSIG records with those algorithms 4) resolver implementations need to continue to support chains that use DNSKEY and RRSIG records that still have SHA1 in them 5) resolver operators may treat DNSKEY and RRSIG records with those algorithms as usable when creating chains, but also might not Note that #4 and #5 are only talking about DNSKEY and RRSIG records; #2 is talking about DS records. Looking through the message chains in the WG, I suspect that was an oversight on our part when all the post-WG changes were being made and not carefully reviewed by the WG. > One late change in the document produced two issues that were only very > recently caught (thanks Mukund for finding these): > > 1. As pointed out, draft-ietf-dnsop-must-not-sha1 states “Validating > resolvers MUST treat RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure”. > This sentence is confusing in that it’s unclear if it is speaking to > implementers or operators. To fix the intent of this, we suggest changing > this to “Validating resolvers MUST be configured to treat RSASHA1 and > RSASHA1-NSEC3-SHA1 DS records as insecure”, directing the requirement toward > those deploying DNSSEC, not those implementing it within validating > resolvers. "those deploying DNSSEC" is confusing, as is "MUST be configured". A simpler, more direct change would be to replace "Validating resolvers" with "Operators of validating resolvers" and leave the rest of the sentence alone. > 2. The document also states “Because of RSASHA1 and RSASHA1-NSEC3-SHA1's > non-zero use, deployed validating resolvers MAY be configured to continue to > validate RRSIG records that use these algorithms.”, which clearly conflicts > with the MUST NOT above. There are two options to fix this in a minimal way: > > 2a. Remove this requirement entirely, as it goes against the principle of the > document to stop using SHA1 (and thus treat it as insecure). > > 2b.Change the MUST in the first sentence to SHOULD NOT so the MAY is no > longer in conflict. The first option seems targeted at that one sentence, not the sentence before it; however, the tho sentences are clearly linked in intent. A different alternative is: 2c. Replace: 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. Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero use, deployed validating resolvers MAY be configured to continue to validate RRSIG records that use these algorithms. with: Operators of validating resolvers MUST treat DNSKEY and RRSIG records that use RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure. Otherwise, we'll be in the silly state of saying "this DS MUST be treated as insecure, but the DNSKEY with the same problem that underlies that DS record might be considered secure". > The authors will look to the chairs and ADs to determine whether > consensus was reached on these specific two decisions and suggest 2 > weeks as a reasonable time frame for a conclusion on this. > > > [no hats]: Speaking personally, I think option 2a is better and signals > what we really want. Operators can already ignore MUSTs without being > told they can do so. This proposed 2c option is more consistent with the rest of the draft, and gives clearer guidance to resolver operators, and prevents us from saying things to implementers that can cause confusion for their customers. It would be my preference for fixing the mess. --Paul Hoffman _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
