Mike Bishop has entered the following ballot position for draft-ietf-dnsop-must-not-sha1-06: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1: The current phrasing of the second sentence in the Introduction suggests that the use of SHA-1 by DNSSEC is an example of its diminishing security; I suspect that's not the intended reading. CURRENT: DNSSEC [RFC9364] originally [RFC3110] made extensive use of SHA-1 as a cryptographic hash algorithm in RRSIG and Delegation Signer (DS) records, for example. CONSIDER: DNSSEC [RFC9364] originally [RFC3110] made extensive use of SHA-1, for example as a cryptographic hash algorithm in RRSIG and Delegation Signer (DS) records. "are now" => "have become" Section 2: "MAY wish to" requires an RFC6919 reference (see https://datatracker.ietf.org/doc/html/rfc6919#section-6) and associated boilerplate. Instead, "MAY" is sufficient here. However, that seems in direct contradiction to the MUST in the first sentence. Is the intended sense here that implementations MUST retain the ability to validate, but SHOULD/MAY disable it by default? _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
