On Mon, Mar 18, 2024 at 8:51 AM David Lawrence via Datatracker < nore...@ietf.org> wrote: > Reviewer: David Lawrence > Review result: On the Right Track > > Early review of draft-ietf-dnsop-dnssec-automation.
Thank you for your detailed review Tale ... > The process itself seems to be reasonably described. I don't have any > suggestions as to the basic steps proposed. > > Questions: > > Section 2 is titled "Use Cases" but 2.1 isn't a use case and shouldn't > be its own section, especially since section 2[.0] has no text. The > short Section 2.2 is the (only?) use case, suggesting that there need > be no separate sections at all and that it should just be titled "Use > Case". If there are other use cases, they should be described. In my view there are actually 2 distinct use cases: (1) Steady State Multi-Signer operation using multiple providers, and (2) Secure Transfer of a signed zone from one provider to another. The first case deals with how to bootstrap a steady state multi-signer configuration, as well as maintain it, in the sense of switching other providers in and out as needed, but the main goal is to always have multiple signers. The second case has a different goal. It uses a strictly temporary configuration of multi-signer to transfer a signed zone from one provider to another, and then moves back to a single signer configuration. (Though the underlying mechanisms are the same). Are you persuaded by this description? > Section 3 says "a zone operator should carefully choose", but > multi-signer has multiple operators. Do you mean to say the zone > owner, or "any one of the zone operators". Maybe it is easier just to > say "Automation of the necessary steps can be categorized into two > main models, centralized and decentralized, and each have pros and > cons," while kind of glossing over just who is making the decision as > the decider is not especially relevant as to standardization. Ok, I think I see what you're saying. Yes, we can say that. > This does lead to further questions in 3.1 though as to just who "the > zone operator" is, with the term again being used as singular and not > having been defined in the Notation section. In common parlance > within the industry, I'd not necessarily call the operator of the > "centralized controller" the "zone operator". Maybe "zone > maintainer", suitably definied earlier, is better? But also the > Notation section just called it an "entity" who runs the controller. "zone operator" in 3.1 is a mistake. It should be the zone owner, or some entity acting on behalf of them, such as the centralized controller. We'll fix that (and also add an entry for zone owner to the notation section). > In Section 4.5 step 9, ZSK/CSK? Yes, ZSK or CSK. Thanks. > > In Security Considerations, I found this to be a little awkward and > not usefully guiding: "Some providers or software installation[s] > allow [who?] to make more specific configuration on the allowed > changes. All extra steps to allows as little access to change zone > data as possible should be taken." I'm not quite sure what is really > being said here. That some are providers/software are too flexible in > what they permit and should be locked down? Perhaps an example would > help. Yes, I agree this text is awkward to read, and I too am unsure what it's saying. Maybe this is just a restatement of the principle of least privilege? Ulrich (Wisser) - do you have any comments? > More minor nits: > > Multi-Signer is inconsistently capitalized throughout. It ought not > to be capitalized. It isn't in RFC 8901 that defines it. Ok. > Section 1.1, "Out-of-Scope", seems superfluous to me. At first I was > going to suggest that the parenthetical which suggested ways of > synchronizing between providers be stricken if it's out of scope to be > discussing it, but on further consideration it feels like the whole > section should be stricken. My view of what this section is trying to say is that this document only deals with zone infrastructure and signing records. Folks deploying multi-signer configurations still need to have a mechanism to keep "data" records updated identically across the providers. This may be obvious though. And if it is to others, then I'm okay with striking this section. > The formatting of the 1.2 Notation section and then the following 1.3 > section is inconsistent with typical draft formatting. These would > typically be combined into a section 2, Terminology. See RFC 9432 for > an example. Sounds good to me. Thanks for providing the example. > > 3.1, "will run controller" -> "will run a controller" Ok. > > "Signer" is inconsistently capitalized. I'd go with consistently > lowercase except, of course, at the start of sentences. Ok. > > 4.1 step 3 says "Signer or controller" then step 4 says just "Signer > controller" and I'm not quite sure how to parse that out. If subject > of each sentence is meant to be the same thing, I'm guessing it is > "Signer controller" without the "or", in which case it should also > probably not have the "Signer" either since prior usage just referred > to role as "controller". I'm a bit confused here too. The controller definition in 1.2 states: Controller An entity controlling the multi-signer group. Used in the decentralized model. But elsewhere (Section 8), we cite the MUSIC software as controller, which is used in the centralized model. So the definition seems reversed. Ulrich (or Johan) - can you review this? > 4.1 step 5, what's a lowercase "must"? It's not clear if the > following "Otherwise" is a statement of what to do if there is no > parent CDS/CDNSKEY/CSYNC scanner or instead is a rationale for why the > scanner requirement is "must" since this is a draft about automation. > If the former, then "must" should be "SHOULD", and if the latter then > "must" should be "MUST". Also the "otherwise" is a dependent phrase > and should be joined with a comma. Hmm, "must" (or MUST) I feel is definitely an overstatement here, particularly since very few TLDs today actually do CDS/CDNSKEY scanning (or signaling changes). I'd prefer your suggestion of SHOULD. And if these mechanism aren't supported, then updates to the parent zone need to be performed some other way. It doesn't necessarily have to be manually either. A centralized controller, given authenticated access to the parent's registration system for the zone, could automate them. > I'd move 4.2 Definitions ahead of 4.1 Prerequisites. Personally I also > wouldn't give it a subsection number, and would use formatting typical > for definition/terminology in RFCs. Yes, I agree. > Out in the wild there's a bit of inconsistency about whether it is > "DNSSEC-signed" or "DNSSEC signed", but personally I believe it should > be hyphenated as a compound adjective. Ok with me. > The algoritm steps refer to DS-Wait-Time, NS-Wait-Time, and > DNSKEY-Wait-Time, but these were previously defined as DS Waiting > Time, NS Waiting Time, and DNSKEY Waiting Time. Ok, we can fix those inconsistencies. Do you prefer hyphenated compound terms here too? > Section 5, the second paragraph as a "therefor" feels like it should > be joined into the first paragraph. That sounds fine, but see my response to Catherine Meadows' review of this section. We are planning to take out the text you refer to here. > For "the following scenarios", add a colon. > > "well supported" -> "well-supported" compound adjective. > > Section 7, IANA Considerations, needs to explicitly say that no IANA > action is needed. Ok. > > Section 8, Implementation Status, should follow Section 9, Security > Considerations. Ok. > > In section 9, "at the right time and date", "and date" is redundant. Yes. > > "Any failure could resolve in" -> "Any failure could result in" Yes. > > "Independently of the chosen model" -> "Independent of the chosen model" Yes. > > "If used correctly the multi-signer algorithm will strengthen the DNS > security by avoiding "going insecure" at any stage of the domain life > cycle." -> "If used correctly, the multi-signer algorithm will > strengthen DNS security by avoiding ever going insecure." Ok. Shumon
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
