Ballot for draft-ietf-dnsop-must-not-sha1
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Needs 7 more YES or NO OBJECTION positions to pass.
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.
# 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
This document is part of a group of 3 I-D. I suggest to start reviewing draft-ietf-dnsop-rfc8624-bis first.