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]
