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]
