John,
On 10/13/23 19:48, John Levine wrote:
I was looking at these two drafts. The first one says that scanning
for CDS updates is bad, so use NOTIFY(CDS) rather than scanning. The
second one says to scan for DS bootstrap.
No, draft-ietf-dnsop-dnssec-bootstrapping doesn't say that at all.
The word "scan" indeed does appear in Section 4.3 ("Triggers"), which says that the
parent SHOULD trigger the DNSSEC bootstrapping process "once one of the following conditions is
fulfilled". It then lists a bunch of possible such conditions, including
1. the parent receives an updated NS RRset,
2. the parent chooses to do a scan,
3. the parent obtains a copy of a signaling zone and walks the signaling
records published there (at _signal.$NS, such as _signal.jo.ns.cloudflare.com),
4. any other condition deemed appropriate,
with the latter one capturing some kind of notification like you suggest, and
method 2 reflecting the existence of corresponding deployments at various
ccTLDs and at RIPE NCC.
I don't see anything here that recommends scanning in particular or otherwise
makes any kind of judgment on what kind of condition is appropriate. It just
says, *if* any such conditions appear to be fulfilled, then please use the
specified procedure for authenticating CDS/CDNSKEY records.
("Scan" also appears in section 5.2 on operational recommendations, where it
says that you shouldn't carry over authentication information between scans, but that
doesn't mean that you should scan. Happy to improve that sentence if you think it's
ambiguous.)
I suggest adjusting the bootstrap draft saying to send NOTIFY(DS) to
the parent of a delegated name to tell it to do the bootstrap rather
than scanning.
The draft is not at all concerned about how the child triggers the parent, but
only with what the parent does *once the parent has determined* that it is
going to attempt DS initialization.
The NOTIFY issue you're raising is very much worthwhile (and I care for it, as you
can see by the fact that we're both co-authors of the NOTIFY(CDS) draft), but that
doesn't mean that it needs to be intermingled with the parent's authentication
mechanism for CDS/CDNSKEY records. KISS, divide & conquer etc.
Bonus update: if we do this, in the bootstrap draft take out section
4.3 on triggers and instead say to use notify.
Besides acknowledging that various trigger mechanisms exist, the takeaway from
Section 4.3 is that the authentication mechanism requires reliable knowledge of
the delegation's NS records; however, depending on the trigger method, this
piece of information may or may not be conveyed directly through the trigger
condition, so a cross-check in the parent's database may be needed.
In particular, methods 1 and 2 above give certain knowledge of what the NS
records are, because the trigger conditions directly derive from processing an
NS RRset that has previously been accepted for delegation.
In contrast, when using method 3 (walking the signaling domain _signal.$NS),
it's possible to encounter signaling records pertaining to domains that are not
delegated to $NS; therefore, the parent has to check that what's found in a
signaling zone matches an actual delegation, and not accept authentication
information from potentially fraudulent signaling records.
This discussion is independent of the notification problem, and I don't think
that it would be helpful to remove it.
The authors also don't see why one should not point out that various triggers
methods exist, and as a result prefer that the section remain in the document.
Thanks,
Nils and Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
