Subject: [DNSOP] Mohamed Boucadair's Discuss on draft-ietf-dnsop-must-not-sha1-06: (with DISCUSS and COMMENT)
From: Mohamed Boucadair via Datatracker <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sun, 13 Apr 2025 02:13:24 -0700
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

Mohamed Boucadair has entered the following ballot position for
draft-ietf-dnsop-must-not-sha1-06: 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:
----------------------------------------------------------------------

Hi Wes, Warren,

Thank you for the effort put into this work. This is a maintenance effort that
is definitely needed.

Thanks for Thomas Graf for his OPSDIR review. This is his first review for
opsdir, btw. Welcome Thomas!

I will be definitely balloting “Yes”, but I have few DISCSS points to be
resolved first. Even if not listed as DISCUSS point, some points in the COMMENT
part need to be fixed (last one, obviously). I have some nits that I will send
you in a PR.

# Process Check

De we need to do anything given that some of the work we are updating falls
under pre-5378?

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

Note that we may not this based on the outcome of the other DISCUSS points

# Authoritative source for recommended DNSSEC Algos

I was naively expecting that we have a document where we say that the
authoritative reference for recommended values is the IANA registry, not
individual RFCs?

Do we have such document? If so, the explicit updates in the draft may not be
required.

# BCP237 Umbrella

As a big fun of BCP237, I wonder whether we should make this more visible in
our DNSSEC “roadmap” documentation and list this document under the BCP237
umbrella?

Of course, this may have implications on the intended status (as currently
set). The status should not be problematic in this case as we have “RFC
Required” (not Standard) policy for both registries. Thanks Paul for RFC6014.

Note that the reco still suggest that validating resolvers to continue
validating, which is reasonable.

Not sure if this was discussed in the past, but I wanted to make sure we have a
record for such discussion.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Expand DNS Public Key (DNSKEY) and resource record digital signature (RRSIG)
in the abstract and introduction.

# Introduction

(1) Reword for better clarity

s/The security of the SHA-1/The security protection provided by the SHA-1

(2) Inappropriate citation

CURRENT: “DNSSEC [RFC9364] originally [RFC3110]..”

I would not cite this specific RFC as this may imply that it is RFC that «made
extensive».

(3)

CURRENT: “Readers are encouraged to consider ..”

Not sure to parse the intent here? Do you mean implementers? Operators? Both?
Please reword accordingly.

(4)

CURRENT: “has been removed from some systems”

May cite an example

# Section 2:

(1)

CURRENT: “Validating resolver implementations MUST ..”

Please add a reference to
https://datatracker.ietf.org/doc/html/rfc9499#section-10.

(2)

CURRENT: “more security strict environments..”

Can we characterize this? Or provide an example? Thanks.

# IANA Considerations

CURRENT: “IANA is requested to set the "Use for DNSSEC Signing" column …”

There is no such column. I guess you meant “Zone Signing”?

# References

You have many references that are listed but not sued (RFC4033, RFC4509,
RFC5702, etc.). Please check these.

Also, there is a problem in how the references are classified. For example, you
list “RFC8174” as informative, while this should be normative. Likewise,
“RFC3110” is listed as normative, while it should be informative.

Cheers,
Med