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 <[email protected]> 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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > Best, > Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
