I'm happy for whichever way you think is best - integrated throughout, or in one specific section - as long as they can be found and recognized as something that requires care.
Deb On Thu, May 21, 2026 at 9:40 AM Peter Thomassen <[email protected]> wrote: > 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]
