[DNSOP] Re: Mohamed Boucadair's Discuss on draft-ietf-dnsop-must-not-sha1-06: (with DISCUSS and COMMENT)

[Wes Hardaker <[e-mail]>]

Mohamed Boucadair via Datatracker <[e-mail]> writes:

Hiya,

Responding to your points inline:

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

We don't think so.  Specifically this document has no pre-existing text
that we're copying from, so don't believe that the pre-5378 stuff
applies.  This document is entirely written from scratch as new.

> # 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.

The IANA registry table is the table we are trying to update which holds
the registry values that indicates the standards level.  You may want to
review our companion document [1] that progressing at the same time that
moves all recommendations into the IANA table because documenting the
list only in an RFC turned out to be problematic.  This document
(must-not-sha1) thus sets the levels to match the recommendation values
for implementation and deployment.

[1]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/

> # 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?

So BCP237 currently only has one document within it (RFC9364).  I think
if we added every future DNSSEC document to the BCP it would likely get
overwhelming.  I would argue that whether or not and how often we should
update BCP237 is a good discussion for the WG as a whole, but it's
outside the scope of this particular document (set).  But that's very much IMHO.

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

Done.  I'm not sure this is standard convention so we'll see if there
are others comments about this.

> # Introduction
> 
> (1) Reword for better clarity
> 
> s/The security of the SHA-1/The security protection provided by the
> SHA-1

Done

> 
> (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».

We could not quite understand what you wanted here, as both references
made sense to us.  Are you saying the RFC9364 or RFC3110 should be removed? 

> CURRENT: “Readers are encouraged to consider ..”
> 
> Not sure to parse the intent here? Do you mean implementers? Operators? Both?
> Please reword accordingly.

Good point, changed to "operators".

> (4)
> 
> CURRENT: “has been removed from some systems”
> 
> May cite an example

I think the references would all be external and likely changing, thus
we can't likely quote them directly.  The one that has been talked about
the most is RedHat's OSes, but I don't think calling them out in this
document would be appropriate.

> # Section 2:
> 
> (1)
> 
> CURRENT: “Validating resolver implementations MUST ..”
> 
> Please add a reference to
> https://datatracker.ietf.org/doc/html/rfc9499#section-10.

done

> (2)
> 
> CURRENT: “more security strict environments..”
> 
> Can we characterize this? Or provide an example? Thanks.

Not likely, as it's a highly subjective discussion that warrants an RFC
or academic or industry white paper in itself.  The security community
will always disagree on the right level of hammer for the right job.

> # 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”?

This document is modifying the table as being modified by the previously
discussed companion document above [1].  That document introduces the
new columns that we're now changing.  This document is, essentially, the
first test of that new process.

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

Done.

> 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.

8174 has been fixed (thanks)

3110 is the basis for what we're modifying as recommended, so IMHO it
should be normative (but is not a hill I'll die on either).

-- 
Wes Hardaker
USC/ISI