Re: [dnsdir] [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-bootstrapping-04

[Peter Thomassen <[e-mail]>]

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/