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

[Scott Rose via Datatracker <[e-mail]>]

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.

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. 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.

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.

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.