Hi Scott, Thank you very much for your feedback -- responses inline.
You can find the changes here (will submit to datatracker before the upcoming cut-off): https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/commit/dcb914737342184c503fbb23fc37c7d3b6e363d1#diff-356ec8c295379536ae015166d01de308455cded000afc5476019b3effbb2ae43 On 6/27/23 19:33, Scott Rose via Datatracker wrote:
Reviewer: Scott Rose Review result: Ready with Issues Review of dnssec-bootstrapping The draft is likely OK to proceed as there are only a few nits that do not change the overall contents. I am confused about if it adds to methods in RFC 8078 or replaces methods in RFC 8078. 1. Abstract: The Abstract says that this draft deprecates the DS enrollment methods in RFC 8078, which implies this draft will replace that text. However the Security Considerations section implies that this draft only adds a new method and removes none of the existing ones (possible just phrasing issue?). If this draft intends to only add a new secure method, the abstract could be changed to say “This document adds the new DS enrollment method to the list of methods described in Section 3 of [RFC8078].” If this is to replace the CDS/CDNSKEY based methods in RFC 8078, then perhaps the first sentence in the Security Considerations section should be updated to say “This draft document replaces the methods described in RFC 8078 Section 3 with a method that adds authentication. Its security level is therefore…” To make it explicit that this draft replaces that section rather than just add another method while retaining the methods previously described in RFC 8078.
The abstract is correct. The confusing sentence in the Security Considerations was supposed to be about the security model (not about the set of methods), where all existing security properties (e.g. CDS validation) remain in place (= removes nothing), but authentication is "added". I agree this was phrased in a confusing way, and I made changes along the lines you proposed.
That is the only potentially confusing issue. The rest are nits: 2. Section 1.1 Terminology: “Parent” and “Child” are defined the same way in the most recent version of the DNS Terminology RFC 8499, so a reference could be used instead of repeating the definition.
Done. (I thought it would be nice to "inline" the actual definition, but that was just a feeling.)
Also, “Signaling Name” sounds confusing compared to the Signaling Domain. Would it be easier to write it as: “Signaling Name The owner name of comprised of a prefix, the Child zone name and the Signaling domain name. Used by the Parental Agent to identify and retrieve the Signaling Type used by the Child zone (See Section 2.2). “ To stress it is a name in the Signaling Domain, but contains the child zone name.
Coming up with this terminology was really challenging. The reason that the Signaling Name is only the prefix, without the Signaling Domain, is that it makes the rest of the spec easier. For example, from Section 3.1: To [...] authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator MUST co-publish them at the corresponding Signaling Name under each out-of-bailiwick Signaling Domain [...] With your definition, one would have to say To [...] authenticate the Child's CDS/CDNSKEY RRsets, the Child DNS Operator MUST co-publish them at each corresponding out-of-bailiwick Signaling Name [...] Do you feel that's an improvement? I appreciate that "Signaling Name" is not ideal. Perhaps instead of making this term the FQDN including the full domain, we should rename "Signaling Name" to something else. Unfortunately, "Signaling Prefix" runs the risk of being mistaken for the "Signaling Type" (which is really a prefix, it's the first label). Taking all this into account, do you have any more suggestions?
3. Section 2.1 Strictly speaking, would the Signaling Zone really need a secure delegation? I could even be an island but the Parental Agent has the Signaling Zone’s SEP key (KSK or ZSK) as an installed trust anchor. If the Parental Agent really only needs to be able to validate RRSIGs in the Signaling Zone, the zone doesn’t necessarily need to have a secure delegation, as it is up to the Parental Agent to validate signatures. Not saying that is easier (it has other problems), just possible so the MUST may be unnecessarily strict.
Done
4. Section 4.2 Parental Agent: Last sentence in paragraph ends “…the cache does not need to get cleared in between.)”. Might be expanded to “…cache does not need be be cleared in between queries to unique Child Zone names.)” for clarity.
Done (along those lines). Thanks, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
