MIME-Version: 1.0
References: 
 <CAF4+nEGTJq-_GOAdFWiW8q-Ci7GU9giP8asn0LojZaZQZCTYXw@mail.gmail.com>
 <d4b32903-8ad8-4c47-99bd-5a9236c5b039@desec.io>
In-Reply-To: <d4b32903-8ad8-4c47-99bd-5a9236c5b039@desec.io>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 17 May 2026 18:37:50 -0400
Message-ID: 
 <CAF4+nEHVs8vA3XXNhDXsOiPR9SAOdptWJ398-PVwG_5C_nxK2Q@mail.gmail.com>
To: Peter Thomassen <peter@desec.io>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: ZLCULLU7NVNDKXLEPT3SAKLYS6KRBSCE
CC: "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>,
 draft-ietf-dnsop-ds-automation.all@ietf.org, Last Call <last-call@ietf.org>,
 "dnsop@ietf.org WG" <dnsop@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_SECDIR_IETF_LC_review_of_draft-ietf-dnsop-ds-aut?=
	=?utf-8?q?omation-05?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/xQc__RCP67W1TKVPgleJagn7tp4>

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=E2=80=AFAM Peter Thomassen <peter@desec.io> wr=
ote:
>
> 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 ex=
amples of security problems that can be caused by ignoring these recommenda=
tions or, if you are sure, to state that there are none (which I doubt). Ho=
w do these recommendations interact with the compromise of various of the p=
arties in the RRR model or with an on-path attacker?
>
> draft-ietf-dnsop-cds-consistency (which is about to be published) is norm=
atively 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 other=
wise be very long. :-) Folks from the WG have specifically pushed to keep t=
his shorter, and to not repeat too many considerations. As an example of th=
e 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 with=
out 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 concer=
n before, I'm doing nothing about this for the moment, unless I hear object=
ions.
>
> [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_2A9V2j=
nuE/

OK, as long as it is covered elsewhere.

> > # Minor
> >
> > Section 4.2.2, last paragraph: Wouldn't there be some advantage to lowe=
ring the TTL of the old DS RRset if you did so early enough before the DS u=
pdate?
>
> 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.  Wi=
th 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.ht=
ml#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 Chil=
d 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 o=
r 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 freq=
uently"? Like, for example, "a few times initially and once a day thereafte=
r".
> > On the other hand, Section 5.2, next to last paragraph says "no more th=
an twice in in a row" so maybe that is what is meant.
>
> Registries expressed that this is not an interoperability requirement, an=
d they would like notification details to be part of their business decisio=
ns. The exemplary guidance "no more than twice in in a row" is therefore gi=
ven in the analysis (Section 5.2) but not the recommendation itself (Sectio=
n 5.1).
>
> I can imagine that gTLD registries might eventually create some policy ab=
out this in the ICANN space, and perhaps it's better for this RFC to not st=
and in the way at that point.

OK.

> > Section 5.2, after the numbered points: Consistent with the tone of oth=
er parts of this document, I suggest "would be justified to attempt communi=
cating" -> "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 deriv=
ation.

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 thi=
s to the IESG. (Context: I believe there was no explicit discussion and I c=
an 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 flap=
ping will only occur for a limited period of time. Is that the only basis f=
or 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. Qu=
oting:
>
>     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 cha=
nge 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" -> "ambigu=
ous"
>
> Already fixed in -06
>
> > Section 4.2.1, first line of last paragraph: perhaps the "may" should b=
e "MAY".
>
> This previously was the case (before -05), but the normative language her=
e was removed upon AD Review.

OK.

> > Section 6.2.2, last line: Some superfluous waffle wording here. "It the=
refore appears that DS initialization and rollovers should ..." -> "DS init=
ialization 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 authen=
tication" -> "the key used for authentication"
>
> Done
>
> > Section 7.2.2, 2nd paragraph: suggest "It is therefore advised to not f=
ollow 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 p=
arenthetical 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/0b89e97dde78126190453d833f8378c52f=
34f430

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

> Best,
> Peter