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.
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. 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 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. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
