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

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]