Deprecating the use of SHA-1 in DNSSEC signature algorithms
draft-ietf-dnsop-must-not-sha1-09

Thanks for this write up. It reads and explains the reasoning well. 

The idnits tool spawns some messages.
 
I have a single idnit observation on this draft. 

74	   RRSIG and Delegation Signer (DS) records, for example.  Since then,
75	   multiple other algorithms with stronger cryptographic strength are
76	   now widely available for DS records and for DNSKEY and RRSIG records.
77	   Readers are encouraged to consider switching to one of the
78	   recommended algorithms listed in the [DNSKEY-IANA] and [DS-IANA]
79	   tables, respectively. 

GV> I am not that familiar with DNSSEC and had to lookup DNSKEY and RRSIG records reference.
Could a reference (rfc4034) be explicitly added for these? Potentially when more familiar with these technologies it is obvious and are well known records through.


Be well,
G/

Thanks to the authors and the WG for this document.

Even though there is no "historic" element in the context of this document as it was for ECC-GOST document, please check/consider if any of those approaches (that I provided in my comments on the ECC-GOST document) are applicable for this document as well.

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?

# Orie Steele, ART AD, comments for draft-ietf-dnsop-must-not-sha1-06 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dnsop-must-not-sha1-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Barry Leiba for the ARTART review.

Thank you to Behcet Sarikaya for the GENART review.

** Section 1 and 2.

-- Section 1. “Further, support for validating SHA-1 based signatures has been removed from some systems.”

-- Section 2. “Validating resolver implementations 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.”

Are these text snippets saying that implementation have already chosen to drop SHA-1 support, despite this draft saying it should not be?

** Section 1.
   As adequate
   alternatives exist, the use of SHA-1 is no longer advisable.

Doesn’t Section 2 say something much stronger than “no longer advisable”.  It uses “MUST NOT”.

** Section 3.
   This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1
   signatures since they are no longer considered to be secure.

Isn’t this imprecise? The prior seems to leave wide latitude to validating resolvers to continue to validate SHA1-based signatures.  Maybe

NEW (roughly)
This document deprecates the use of RSASHA1 and RSASHA1-NSEC3-SHA1 signatures in new DNSSEC records since these algorithms are no longer considered to be secure.