Reviewer: Jim Reid Review result: On the Right Track I am the latest dnsdir stuckee to review the document. I'm sorry to say it needs more work, mostly to correct too many minor niggles.
1) The text in the Introduction does not scan well. I think the following is better/clearer: RFC8901 describes the necessary steps and API for a multi-signer DNSSEC configuration. This document combines elements of RFC8901, RFC8078 and RFC7477 to define a process for automating the setup, operation and decomissioning of a multi-signer DNSSEC configuration. One of the special cases of multi-signer DNSSEC is the secure change of DNS operator. Using Model 2 of the multi-signer specification defined in RFC8901 achieves this. [Comment: are there other special (DNSSEC automation) cases that could/should be covered here?] 2) Section 1.1 is clunky IMO. Saying the zone contents need to be synchronised is a content-free statement of the bleedin' obvious. I think it shouldn't need to be said that arranging how that synchronisation gets done is out of scope for the I-D. Why not also make equally empty statements that key generation methods, entropy sources, choices of algorithms, key lengths, etc are out of scope? 3) IMO the boilerplate references to RFC Normative Language shouldn't be in the same section as the local definitions for Signer, Parent and so on. 4) Many of the definitions don't define anything! DS-Wait-Time for example. Others are missing: Trust Mechanism for instance. 5) Change the two paras at the start of Section 3 to: As explained in RFC8901 a multi-signer DNSSEC configuration presents some challenges. These can be addressed by following the steps for setup and operation described below. 6) I don't like "going insecure". Maybe this should be a definition? 7) The opening para of Section 4 is another content-free statement of the bleedin' obvious. Either delete it or provide more text on the advantages and disadvantages of both models. Everything has pros and cons, but what are they? 8) s/example will/example. 9) Why single out TSIG authentication? This is not the only game in town for "securing" dynamic updates. And if the text on TSIG is to remain, the doc needs to have a reference to RFC8945. 10) It's decentralised model, not models. 11) s/will communicate/communicate/ 12) It would be helpful to explain what sort of configuration details are not part of the zone data. 13) Just say "add and remove DNSKEY, CDS, CDNSKEY and CSYNC RRs"? Same outcome, fewer words... 14) I think Section 4.3 should start "For both the centralised and decentralised models..." BTW, I hope you've realised by now I *hate* American spelling. :-) 15) In Section 5, more clarity is needed on what "waiting times" and "timing restrictions" mean within the context of the I-D. They don't seem to be defined. 16) What does "A working setup of the zone, including DNSSEC signing" mean? For me, DNSSEC signing seems orthogonal to whatever a working setup of the zone actually means. Besides, broken zone setups can be signed, can't they? 17) same algorithm for DNSSEC signing as the rest of the multi-signer group 18) Please change "and keys from others signers" to "keys used by others in the multi-signer group". 18) The signer or controller. 19) "a CSYNC scanner, updates updates to the parent zone have to be made by some out of band method, perhaps manually." 20) Establish a trust mechanism between the multi-signer group and the newly introduced signer. 21) I don't understand what "Add ZSK for each signer to all other signers." means. If the zone contents are synchronised across the signers in the group as they're supposed to, surely they already have all the ZSKs and related DNSSEC metadata. Or have I missed something obvious? 22) Remove/replace CDS/CDNSKEY Records from all signers. Shouldn't this be mandatory? 23) Is this the maximum of DS-Wait-Time or DNSKEY-Wait-Time? Or is it wait for DS-Wait-Time + DNSKEY-Wait-Time? 24) "publish a CSYNC record with NS and A and AAAA bit set on all signers." And why all signers? Surely this only needs to be done on the signers that have the incorrect glue and/or NS RRset? 25) Wait for Parent to publish NS RRset. How long do they wait? 26) At 5.5.6, Remove old ZSK from DNSKEY RRset of all signers 27) At 5.6.7, "... its DNSKEY RR set and removes..." 28) There probably need to be a few MUSTs/SHOULDs/MUST NOTs in Section 5. 29) Opening para of Section 6 is clunky. How about "To ensure consistent behaviour by validating resolvers, all signers in a multi-signer group MUST use the same algorithm(s) to ensure consistent behaviour by validating resolvers"? 30) The para "This section tries to summarize why that is the case and trade-offs can be made in situations where using the same algorithm isn't possible." is poorly worded. For starters, an I-D/RFC shouldn't be trying to do something. Either this ID summarises something or it doesn't. 31) Section 6 seems to contradict itself. It starts off saying signers need to use the same algorithm and then says they don't. I'm confused. 32) s/We have to// 33) "Any failure..." of what? And what is meant by "executed at the right time"? Presumably these are the steps outlined in Section 5. If that's the case, say so! 34) s/will be able to change/are able to change/ 35) The github URL should be removed IMO. github is outside the IETF's control and therefore shouldn't be mentioned in a standards-track RFC. YMMV. I can't find any DNS RFC that references github cruft. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
