Hi Donald, Peter, all, On this one:
> 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". I tend to agree with Donald suggestion. That channel is needed for resilient/robust maintenance operations. Cheers, Med > -----Message d'origine----- > De : Donald Eastlake <[email protected]> > Envoyé : lundi 18 mai 2026 00:38 > À : Peter Thomassen <[email protected]> > Cc : [email protected]; secdir <[email protected]>; draft-ietf-dnsop-ds- > [email protected]; Last Call <[email protected]>; > [email protected] WG <[email protected]> > Objet : Re: SECDIR IETF LC review of draft-ietf-dnsop-ds- > automation-05 > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > ietf.org%2Farchive%2Fid%2Fdraft-ietf-dnsop-cds-consistency- > 11.html%23n > > ame-failure-scenarios-due-to- > in&data=05%7C02%7Cmohamed.boucadair%40ora > > > nge.com%7Cb67e91a5b93b47ff203808deb464f9fc%7C90c7a20af34b40bfbc48b > 9253 > > > b6f5d20%7C0%7C0%7C639146542943083199%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0e > > > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIld > > > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v4xqNp3seFaIN4rlO77GFNuvKV25INhMY > PiJ5 > > SgSWuc%3D&reserved=0 > > [2]: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mail > > > archive.ietf.org%2Farch%2Fmsg%2Fdnsop%2F5jVEyldeIuPOFu917_2A9V2jnu > E%2F > > > &data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb67e91a5b93b47ff2 > 0380 > > > 8deb464f9fc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639146542 > 9431 > > > 11837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > MDAw > > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C& > sdat > > a=3DWkMW3%2BeNBCmPUpnrt%2BVOLrJuj7PFLKNKZkqwSV9JQ%3D&reserved=0 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > ietf.org%2Farchive%2Fid%2Fdraft-ietf-dnsop-ds-automation- > 01.html%23nam > > e-approaches-not- > pursued&data=05%7C02%7Cmohamed.boucadair%40orange.com > > > %7Cb67e91a5b93b47ff203808deb464f9fc%7C90c7a20af34b40bfbc48b9253b6f > 5d20 > > > %7C0%7C0%7C639146542943126644%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGki > > > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ > > > %3D%3D%7C0%7C%7C%7C&sdata=jmiReIFVvNZEwG2SbkkinZdi%2BhNoTKxrFecmMD > HsKa > > I%3D&reserved=0 > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gith > > ub.com%2Fdesec-io%2Fdraft-ietf-dnsop-ds- > automation%2Fcommit%2F0b89e97d > > > de78126190453d833f8378c52f34f430&data=05%7C02%7Cmohamed.boucadair% > 40or > > > ange.com%7Cb67e91a5b93b47ff203808deb464f9fc%7C90c7a20af34b40bfbc48 > b925 > > > 3b6f5d20%7C0%7C0%7C639146542943141348%7CUnknown%7CTWFpbGZsb3d8eyJF > bXB0 > > > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > IsIl > > > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=y5OZ6L7g0JTAL4R7v2tAJxOhRWxETvoS > B3yy > > mc%2BFxfk%3D&reserved=0 > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > > > Best, > > Peter ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
