Paul Wouters has entered the following ballot position for draft-ietf-dnsop-must-not-sha1-07: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I very much plan to say Yes, after one error is fixed in the document: This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 for DNSSEC Delegation and DNSSEC signing I think "DNSSEC Delegation" here is wrong. That is hashing, not signing and it does not use RSASHA1 or RSASHA1-NSEC3-SHA1 which are DNSKEY Signing algorithm numbers and not DNSSEC Delegation Signer algorithm numbers. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Zone owners currently making use of SHA-1 based algorithms should immediately switch to algorithms I would use "should immediately rollover to algorithms" to avoid the illusion some inexperienced DNS admins might have that they can just "switch" the algorithm without proper prep work of doing a real roll over. And the Operational Considerations that I thought should be removed from draft-ietf-dnsop-rfc8624-bis would actually make sense here :) As a result, SHA-1 is no longer fully interoperable in the context of DNSSEC. As adequate alternatives exist, the use of SHA-1 is no longer advisable. That should be, "SHA-1 as part of a signature algorithm". Because the document isn't obsoleting SHA-1 from DS hashing algorithms right? 2. Deprecating RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms in DNSSEC Can the title include "signing" in the name to clarify validating is still okay? Should it state that SHA1 as part of the NSEC3 algorithm itself is also not obsoleted? Perhaps this can be avoided if the rest of the document can strongly bind the obsoleting of SHA-1 to "signing algorithm". In the Operational Considerations, one could add a sentence about the difference of not supporting SHA-1 versus having a system that does not support SHA-1. The first results in an insecure validation, which is okay. The second can result in ServFail, which is not okay. Something along the lines of: When not supporting or disabling SHA-1, care should be given by implementers that the DNS software itself is made aware not to consume SHA-1. For example, disabling SHA-1 at the Operating System level could result in SHA-1 cryptographic failures within the DNS system, which would result in those zones failing, instead of the zones being treated as unsigned/insecure _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
