[DNSOP] Re: Deb Cooley's No Objection on draft-ietf-dnsop- ds-automation-08: (with COMMENT)

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]