Ballot for draft-ietf-dnsop-nsec3-guidance
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
My DISCUSS and comments were addressed in -09. Thanks! Good document, nice to see operations feedback back into the IETF via a new BCP. Resolved 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 :) Resolved 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 :)
Thank you for the work on this document. Before reading Alvaro's comment, I was going to bring up that the following paragraph in Section 3.2 could be confusing for a reader who is aware of the "Updates" RFC header. Note that this specification updates [RFC5155] by significantly decreasing the requirements originally specified in Section 10.3 of [RFC5155]. See the Security Considerations for arguments on how to handle responses with non-zero iteration count. I see that Alvaro is questioning if this doc should actually update 5155, I personally don't have a strong opinion, and don't think it is absolutely necessary, although I am curious to hear if there has been discussion in the community about it. In any case I think it would be good to rephrase the above paragraph to avoid saying that this doc updates 5155 when it doesn't. Thanks, Francesca
Thanks for this document, I found it easy to read and useful. I have only a few nits: 1. In the Introduction: “This sacrifices the tamper-resistance proof of non- existence offered by NSEC3” That doesn’t parse. Probably what you mean is “This sacrifices the tamper-resistance of the proof of non-existence offered by NSEC3” (added “of the”)? Or "... the tamper-resistant proof" would also work. 2. In Sections 2.4 and 3.1, I suggest “re-signing” (signing again) instead of “resigning” (quitting). 3. Appendix B has “The table (Appendix C) below” The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I guess you either should caption it and xref that caption, or just remove the xref?
I support Paul's DISCUSS; basically, "What Roman said". Also, for possible IESG conversation: Is it weird at all that a BCP is updating a Standards Track document? A very minor point: I don't think you need Section 2.1. I'm pretty sure the reference to RFC 8174 needs to be normative; it's part of the same BCP as RFC 2119, which you do already have as normative. In Section 2.2: OLD: "... whether or not that NSEC3 record provides proof of non-existence or not." NEW: "... whether that NSEC3 record provides proof of non-existence." Regarding the SHOULD in Section 3.2, what other action might a resolver legitimately return, and why? Same question for the SHOULD in Section 4. Why wasn't Appendix E done in the form of BCP 205? Is the intent to keep it when the draft is published as an RFC?
** I support Paul Wouter’s DISCUSS position. Like Alvaro and Francesca also commented, this document appears to be changing the behavior of RFC5155. It should formally update it in the meta data. Specifically: -- The language in Section 3.2. appears to “weaken” the guidance in Section 10.3 of RFC5155 -- Section 3.2 also seems to explicitly say it is updating RFC5155 with “[n]ote that this specification updates [RFC5155] …” ** Section 2. The following sections describe recommendations for setting parameters for NSEC3 and NSEC3PARAM. I don’t believe this is accurate. There are few tangible recommendations about iterations or salts in this section. That’s in Section 3. ** Section 2.2. In general, NSEC3 with the Opt-Out flag enabled should only be used in large, highly dynamic zones with a small percentage of signed delegations. Operationally, this allows for fewer signature creations when new delegations are inserted into a zone. This is typically only necessary for extremely large registration points providing zone updates faster than real-time signing allows or when using memory-constrained hardware Qualitative scales such as “large … dynamic zones” and “extremely large registration points” used. Can the operational experience informing these statements be cited to suggest the scale? ** Section 3.1. Operators are encouraged to forgo using a salt entirely by using a zero-length salt value instead (represented as a "-" in the presentation format). Section 2.4 seemed to take a stronger position on the lack of utility of the salt. Is there a reason normative language isn’t being used?
Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Tim Wicinski for the shepherd's write-up and the WG consensus, I would have appreciated a little more text about the intended status though. I hope that this helps to improve the document, Regards, -éric I share other ADs' comments about the lack of formally updating ## Section 2 Suggest to change the title s/considerations/discussions/ as this section explains the recommendations of section 3. ## Section 3.2 S/near the time of publication/near the time of publication of this document/ ? ## Section 7.1 RFC 8174 should be normative # NITS ## Section 1 Should "zone apex" be explained ? ## Appendix C I am not sure whether Peter Špaček appreciates his last name writing in the I-D ;-) (my first name, Éric, suffers from the same issue ;-) )
Should this document formally Update RFC5155? Besides providing "guidance on setting NSEC3 parameters", there is also Normative language that seems similar to what is in rfc5155, but not the same. For example: In §3.2 this document says: Validating resolvers MAY return an insecure response to their clients when processing NSEC3 records with iterations larger than 0. Note also that a validating resolver returning an insecure response MUST still validate the signature over the NSEC3 record to ensure the iteration count was not altered since record publication (see [RFC5155] section 10.3). I couldn't find text in rfc5155 about how returning insecure responses is optional, but I did find this in §10.3 that seems related to the validation requirement: A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct. Reading further, §3.2 does say that "this specification updates [RFC5155]", but there's no indication in the header or anywhere else.
Thanks for the work put into this document. Having read through the document, I would also like to support Paul's discuss since the document does seem to update RFC5155. I also would like to second what Murray said about it seeming a little strange to see a BCP document updating a standards track document. Finally - I was a little surprised to see IANA actions in a document entitled "guidance for...." - not sure if anyone else agrees with me, but it seems strange to see a BCP document requesting IANA actions
# GEN AD review of draft-ietf-dnsop-nsec3-guidance-08 CC @larseggert Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/s5hyTc3FVrHGhUW0kHVOGLVXTgo). ## Comments ### Section 3.2, paragraph 4 ``` Validating resolvers returning an insecure or SERVFAIL answer to their client after receiving and validating an unsupported NSEC3 parameter from the authoritative server(s) SHOULD return an Extended DNS Error (EDE) {RFC8914} EDNS0 option of value (RFC EDITOR: TBD). Validating resolvers that choose to ignore a response with an unsupported iteration count (and do not validate the signature) MUST NOT return this EDE option. ``` {RFC8914} looks like a Markdown citation bug. ### Missing references No reference entries found for: `[RFC8914]` and `[draft-hardaker-dnsop-nsec3-guidance]`. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Stray characters The text version of this document contains these HTML entities, which might indicate issues with its XML source: `č`, `Š`, and `Č` ### Grammar/style #### "Table of Contents", paragraph 1 ``` . . . . . . . . . . 10 Appendix D. Github Version of This Document . . . . . ^^^^^^ ``` The official name of this software platform is spelled with a capital "H". #### Section 1.1, paragraph 1 ``` lag [RFC5155], which specifies whether or not that NSEC3 record provides pro ^^^^^^^^^^^^^^ ``` Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". #### Section 2.3, paragraph 1 ``` w, ftp, mail, imap, login, database, etc) can be used to quickly reveal a lar ^^^ ``` A period is needed after the abbreviation "etc.". #### Section 5, paragraph 1 ``` y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/R ^^^^^^^ ``` Do not mix variants of the same word ("on-line" and "online") within a single text. #### Section 7.1, paragraph 2 ``` NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements ^^ ``` Two consecutive dots. #### "Appendix A.", paragraph 2 ``` Vixie * Tim Wicinski Appendix D. Github Version of This Document While this ^^^^^^ ``` The official name of this software platform is spelled with a capital "H". ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Hi, Thanks for this document. I found it mostly to be easy to read. One minor point, I found it slightly confusing in various places as to whether "iterations" meant "total number of interactions" or the "iterations parameter" that refers to the number of extra interactions. Hence I would suggest changing "iterations" to "iterations parameter" or "extra iterations" or "total iterations" in various places depending on the context to ensure that this it is clear/obvious in all places. Regards, Rob