[DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-dnsop-nsec3-guidance-08: 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-nsec3-guidance/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

#1:  This document updates RFC 5155 but has no Updates: clause and no reference
of this in the Abstract. In case this would not be seen as an Update:able
offense, then the text "Note that this specification updates [RFC5155]" should
be changed :)


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

Good document, nice to see operations feedback back into the IETF via a new BCP.

comments:

     The algorithm field is not discussed by this document.

Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are
discussed?

    The NSEC3PARAM flags field currently contains no flags, but
    individual NSEC3 records contain the "Opt-Out" flag

This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the
opt-out flag:

https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1

Maybe a sentence more clearly stating there is currently only one flag defined
and that is opt-out and then discuss it.

    are encouraged to use a flags value of 0 (zero)

And rewrite this to say "are encouraged to not use the opt-out flag" so if in
the future we define another flag, we don't have to errata or Update: this
document for this one line mentioning 0.

   The first
   hash is typically sufficient to discourage zone enumeration performed
   by "zone walking" an NSEC or NSEC3 chain.

NSEC uses no hashing, so this sentence reads a little odd. Perhaps:

   The first
   hash with NSEC3 is typically sufficient to discourage zone enumeration
   performed by "zone walking" an unhashed NSEC chain.

   If NSEC3 must be used, then an iterations count of 0 MUST be used to
   alleviate computational burdens.

I think we need a sentence here (or in the section 2.4 above) that explains the
iterations count of 0 means 1 hashing operation is done. Eg it is an "extra
iteration count". I'd like to prevent implementors from thinking nsec3 can be
unhashed completely.

Appendix D needs a note to the RFC Editor to remove itself.

Appendix E lists a bunch of implementations. Normally, this would be placed in
an Implementation Status section, that is removed before publication. Should
this section really be contained within this document?

nits:

"within the Internet" ? I'd probably use "on the Internet" :)

"tamper-resistance proof" -> "tamper-resistant proof" ?

"repeating that hashing algorithm" -> "repeating that hashing using the same
algorithm"

Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less
credit we give it, the better :)

    in deploying both RFC4470 or NSEC3

This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"

"and the zone resigned."   -> "and the full zone needs to be resigned."

"and lower their default acceptable limits over time." -> "but lower their
default acceptable limits over time."

There is a weird rendering of  {RFC8914} instead of [RFC8914]

I think Petr Špaček would like to see his last name fixed :)