[DNSOP] Re: SECDIR IETF LC review of draft-ietf-dnsop-ds-automation-05

[Donald Eastlake <[e-mail]>]

Hi Peter,

Sorry for the delay in response.

As below, I consider my comments to have been resolved except for my
one comment that in Section 7.2, poiny 1, to replace "SHOULD" with
"MUST". However, I am content, as you suggest, to leave this up to the
IESG.

On Thu, May 14, 2026 at 6:39 AM Peter Thomassen <[e-mail]> wrote:
>
> Hi Donald,
>
> Thank you for your review! Please see inline.
>
> On 5/11/26 01:18, Donald Eastlake wrote:
> > this is much more of an operations BCP than a security BCP.
> [...]
> > # Security
> >
> > I believe there are security threats addressed by this document but it seems to mostly focus on potential operational problems of "inconsistency" and "unexpected and confusing" behavior. It might be useful to give some examples of security problems that can be caused by ignoring these recommendations or, if you are sure, to state that there are none (which I doubt). How do these recommendations interact with the compromise of various of the parties in the RRR model or with an on-path attacker?
>
> draft-ietf-dnsop-cds-consistency (which is about to be published) is normatively referenced by the draft at hand, and contains an entire appendix [1] on what can go wrong if consistency requirements are not honored.
>
> The current document is supposed to give operational guidance without re-describing everything that has been said in other documents. It would otherwise be very long. :-) Folks from the WG have specifically pushed to keep this shorter, and to not repeat too many considerations. As an example of the WG discussion, see [2] (search for "RFC 6781" therein).
>
> While I'm of course open to adjusting text, I don't see how to do it without challenging the WP's consensus. As you also said "this is much more of an operations BCP than a security BCP" and nobody has brought up the concern before, I'm doing nothing about this for the moment, unless I hear objections.
>
> [1]: https://www.ietf.org/archive/id/draft-ietf-dnsop-cds-consistency-11.html#name-failure-scenarios-due-to-in
> [2]: https://mailarchive.ietf.org/arch/msg/dnsop/5jVEyldeIuPOFu917_2A9V2jnuE/

OK, as long as it is covered elsewhere.

> > # Minor
> >
> > Section 4.2.2, last paragraph: Wouldn't there be some advantage to lowering the TTL of the old DS RRset if you did so early enough before the DS update?
>
> No. An old revision [3] contained the following text (in an appendix on "Approaches not pursued", which the WG later decided to drop):
>
> OLD
>     It is not necessary to equally reduce the old DS RRset's TTL before
>     applying a change.  If this were done, the rollover itself would have
>     to be delayed [for this extra step] without any apparent benefit.  With the goal of
>     enabling timely withdrawal of a botched DS RRset, it is not equally
>     important for the previous (functional) DS RRset to be abandoned very
>     quickly.  In fact, not reducing the old DS TTL has the advantage of
>     providing some resiliency against a botched DS update, as clients
>     would continue to use the previous DS RRset according to its normal
>     TTL, and the broken RRset could be withdrawn without some of them
>     ever seeing it.  Wrong DS RRsets will then only gradually impact
>     clients, minimizing impact overall.
>
> [3]: https://www.ietf.org/archive/id/draft-ietf-dnsop-ds-automation-01.html#name-approaches-not-pursued

OK.

> > Section 4.2.3, last paragraph: I found this paragraph a little hard to understand. What exactly does "Child DNS operators are held responsible for publishing contradictory information" mean? Isn't it just that when a Child DNS operator publishes contradictory information, the parent rejects it?
>
> It's supposed to mean that Child DNS operators have the responsibility to publish consistent information across auths: if they don't, the parent won't second-guess what the intention could have been; it simply won't work.
>
> I agree that this sentence is not very clear, and applied a fix. In doing so, I've also swapped another sentence around for flow:
>
> OLD
>     If both RRsets are published, Parents are expected to verify
>     consistency between them by verifying that they refer to the same set
>     of keys [I-D.ietf-dnsop-cds-consistency].  The CDS digest field need
>     only be verified when the hash digest algorithm is designated as
>     "MUST" in the "Implement for DNSSEC Delegation" column of the "Digest
>     Algorithms" registry [DS-IANA], and may otherwise be ignored when the
>     digest type is unsupported.
>
>     By rejecting the DS update if RRsets are found to be inconsistent,
>     Child DNS operators are held responsible when publishing
>     contradictory information.  Note that this does not imply a
>     restriction to the hash digest types found in the CDS RRset: if no
>     inconsistencies are found, the parent can publish DS records with
>     whatever digest type(s) it prefers.
>
> NEW
>     If both RRsets are published, Parents are expected to verify
>     consistency between them by verifying that they refer to the same set
>     of keys [I-D.ietf-dnsop-cds-consistency].  By not second-guessing
>     inconsistencies (such as by RRset recency) and instead rejecting
>     them, responsibility to clearly express each update request is placed
>     on the Child DNS operator.
>
>     The CDS digest field need only be verified when the hash digest
>     algorithm is designated as "MUST" in the "Implement for DNSSEC
>     Delegation" column of the "Digest Algorithms" registry [DS-IANA], and
>     may otherwise be ignored when the digest type is unsupported.  Note
>     that this does not imply a restriction to the DS hash digest types:
>     if no inconsistencies are found, the parent can publish DS records
>     with whatever digest type(s) it prefers.

OK.

> > Also, doesn't a parent always have the power to publishes whatever DS or other records it wants?
>
> Yes, of course.
>
> > Section 5.1, point 3: Since there are specific recommendations in many other cases, can something specific be said rather than "unnecessarily frequently"? Like, for example, "a few times initially and once a day thereafter".
> > On the other hand, Section 5.2, next to last paragraph says "no more than twice in in a row" so maybe that is what is meant.
>
> Registries expressed that this is not an interoperability requirement, and they would like notification details to be part of their business decisions. The exemplary guidance "no more than twice in in a row" is therefore given in the analysis (Section 5.2) but not the recommendation itself (Section 5.1).
>
> I can imagine that gTLD registries might eventually create some policy about this in the ICANN space, and perhaps it's better for this RFC to not stand in the way at that point.

OK.

> > Section 5.2, after the numbered points: Consistent with the tone of other parts of this document, I suggest "would be justified to attempt communicating" -> "SHOULD communicate"
>
> This a derivation of the recommendation and not the recommendation itself. The SHOULD in recommendations 5.1.1-5.1.3 is the conclusion of that derivation.

OK. I guess the analysis/recommendation separation in this document is
not that common in IETF BCPs.

> > Section 7.1, point 1: "SHOULD" -> "MUST" ?
>
> Fair point. As this technically would change WG consensus, I'll leave this to the IESG. (Context: I believe there was no explicit discussion and I can imagine nobody feels strongly.)

I guess we will see what the IESG does.

> > Section 7.2.3, 1st paragraph: I understand the basis for saying DS flapping will only occur for a limited period of time. Is that the only basis for saying it will only be a minor nuisance?
>
> The main point is that even when there is DS flapping for some period of time, both variants of the DS RRset will be valid, so it doesn't matter. Quoting:
>
>     lead to flapping of DS updates.  However, it is not expected to be
>     harmful as either DS RRset will allow for the validation function to
>     continue to work, as ensured by Recommendation 1b of Section 4.  The
>     effect subsides as the Child's state eventually becomes consistent
>     (roughly, within the child's replication delay); any flapping until
>     then will be a minor nuisance only.
>
> As you didn't make a suggestion and I believe the text says the thing you raised, I did not apply a change for now.

OK.

> > # Nits
> >
> > Section 3, 2nd paragraph, first sentence. Not grammatical. Simplest change would be to delete "as" but it is also too wordy. Suggest shortening to "Recommendations in this document optimize interoperability and safety."
>
> Done
>
> > Section 4.1 point 1a and Appendix A.1, point 1a: "ambigious" -> "ambiguous"
>
> Already fixed in -06
>
> > Section 4.2.1, first line of last paragraph: perhaps the "may" should be "MAY".
>
> This previously was the case (before -05), but the normative language here was removed upon AD Review.

OK.

> > Section 6.2.2, last line: Some superfluous waffle wording here. "It therefore appears that DS initialization and rollovers should ..." -> "DS initialization and rollovers SHOULD ..."
>
> Done
>
> > Section 7.1, point 5: "has declared to be performing automated" -> "has declared it performs automated"
>
> Done (with "that" added), also in summary A.4.

OK.

> > Section 7.2.1, 1st paragraph, 2nd sentence: "the key used by for authentication" -> "the key used for authentication"
>
> Done
>
> > Section 7.2.2, 2nd paragraph: suggest "It is therefore advised to not follow this practice." -> "This practice is NOT RECOMMENDED."
>
> Done
>
> > Section 7.2.2, 4th paragraph: ends with a parenthetical where I believe the parens are not needed. Check for other cases of this in the document.
>
> Prefer to keep it, as otherwise it reads like a restriction whereas the parenthetical is for context only.

OK.

> > Section 11: Spell out SSAC on first use.
>
> Done.
>
> The combined diff of the above changes is here: https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/0b89e97dde78126190453d833f8378c52f34f430

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Best,
> Peter