Hi Deb, Thank you very much for your review!
I'm providing a response before the telechat to keep folks in the loop about editing plans, but I haven't written actual text. I expect to provide it later today. Please see below for details. On 5/21/26 00:49, Deb Cooley via Datatracker wrote:
---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Donald Eastlake for their secdir reviews. I'm making this a no obj ballot, but I would like it to be carefully considered. I'm happy to chat about it, if that makes it easier. Classically for Security Considerations, one would reference a RFC (or I-D) that outlines the existing pitfalls and issues. Outside of the security area drafts, a normal draft doesn't put these considerations throughout the draft. However, we are not opposed to this idea. In the author's response to the secdir review, the draft-ietf-dnsop-cds-consistency was mentioned as covering this concern. Upon review, it appears that this draft is referenced in Sections 4.1, 4.2.1, 4.2.3 (and Appendix A.1, which I assume is merely informative). This assumes that there are no security considerations for any of the other sections, such as Section 4.2.2, Section 5 (can notifications be spoofed?), Section 6 or Section 7. Is this true?
Those are good suggestions. Here's the outline for an updated Security Considerations section: Section 4: As suggested (?) by you, I'll add a note referring to draft-ietf-dnsop-cds-consistency, and also say a word about key compromise as suggested by Mahesh. I'm not aware of any security considerations for section 4.2.2. Section 5: Notifications can be spoofed, but are informative only (they don't carry an update payload, but merely cause the parent to start looking for an update request immediately instead of based on a scheduled scan). RFC 9859 recognizes this in its own "Security Considerations" section, and points out there's no adverse effects beyond unnecessary checks, which (for extreme cases) are recommended to be mitigated using rate limiting. I'll add this, including a reference. Section 6: The security considerations for this are in Section 6.2.1, where the security properties of update locks are laid out and put into context with DS automation. Section 7: As suggested by Mahesh, I'll add a note about automated DS removal (which is not new, but included here from RFC 8078). I'm not aware of any security considerations for the rest of the section.
It would be simpler (for both the authors and the readers), if the security considerations were all in one place. The authors can reference the appropriate pre-existing RFC/I-D which keeps the current draft short and to the point, focused on the operational concerns.
That certainly makes sense! Best, Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
