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

Nicely done.  TYVM for the time and effort!

Deb Cooley

On Thu, May 21, 2026 at 4:24 PM Peter Thomassen <[email protected]> wrote:

> Hi Deb & other IESG members,
>
> As described in the previous email, I've drafted text to replace the
> Security Considerations section as shown below. The full diff from -08 is
> seen in
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-ds-automation-08&url2=https://desec-io.github.io/draft-ietf-dnsop-ds-automation/draft-ietf-dnsop-ds-automation.txt
> .
>
> AFAI'm aware, this clears the last to-do item. I'll give folks time to
> review until tomorrow, and will then submit the new revision for
> publication. Thanks everyone for the thorough review, it was worth it!
>
> NEW
>     The recommendations in this document are designed to improve the
>     safety and interoperability of DNSSEC delegation maintenance.
>     Relevant security implications and various trade-offs are explained
>     in the analysis subsections above.  This section notes additional
>     aspects worth considering.
>
>     When inconsistencies between CDS/CDNSKEY RRsets are ignored (contrary
>     to Recommendation 4.1.1.a), a number of security risks result.  For
>     example, when a nameserver domain expires and is re-registered
>     maliciously, the adversary may be able to initialize a DS RRset and
>     subsequently redelegate the domain using CSYNC synchronization
>     [RFC7477], resulting in a full hijack of the domain.  For details,
>     refer to [I-D.ietf-dnsop-cds-consistency], Appendix A.
>
>     Similar risks of total adversarial control exist when the child's SEP
>     key is compromised, as this key can authorize DS update or removal
>     requests if consistently published on all nameservers.  This
>     reinforces that loss of key control poses severe risks; utmost care
>     must be taken when managing SEP keys.
>
>     When a domain is stripped of its DNSSEC protection by removing the DS
>     RRset — either manually or using an automatic delete signal
>     (Recommendation 7.1.3) —, DNSSEC security guarantees and associated
>     benefits are no longer in effect.  For example, an email operator may
>     enforce DANE for domains previously observed to support it, and as a
>     result experience a service disruption in email delivery.  Both child
>     and parent DNS operators MUST take such service disruptions into
>     account when considering removal of the DS RRset for their zone.
>
> This change is recorded in commit
> https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/4926c618bf2386dbddb6f84976149d104e2b3405
> .
>
> @Deb: In my earlier message, my comment on notification spoofing was
> different from the above. That was because I thought you were talking about
> RFC 9859 notifications, but then I realized you meant the ones from Section
> 5. So, please disregard my previous comment.
>
> Best,
> Peter
>
>
> On 5/21/26 15:40, Peter Thomassen 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
>
> --
> Like our community service? 💛
> Please consider donating at
>
> https://desec.io/
>
> deSEC e.V.
> Möckernstraße 74
> 10965 Berlin
> Germany
>
> Vorstandsvorsitz: Nils Wisiol
> Registergericht: AG Berlin (Charlottenburg) VR 37525
>
>

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]