Hi Paul,
You said in the end of your message that "none of these are blocking issues for me.
The WG can resolve these as it sees fit." That's also how I feel; as the current
text was approved by the WG, I'll wait for the WG to chime in for any changes.
Some more comments below.
On 11/18/25 18:59, Paul Wouters wrote:
> During initial DS provisioning (DNSSEC bootstrapping), conventional
DNSSEC
> validation for CDS/CDNSKEY responses is not (yet) available; in this
case,
> authenticated bootstrapping ([RFC9615]) should be used.
>
> Or a regular EPP method can be used instead of trying to bootstrap
through DNS.
This is in the CDS/CDNSKEY section, explaining how to use that technique
properly (which entails updates and bootstrapping).
It is basically saying, this paragraph is for DS updates. If you are going from
insecure to secure, this paragraph does not really apply
No, it does not say that. Consistency is always required, also when going from insecure
to secure. In case of RFC 9615, that's indeed ensured by the requirements of that method,
but that is not the only in-band method for initializing a DS RRset: there is still RFC
8078 Section 3, which includes things like "Accept after Delay".
"Accept after Delay" was not deprecated by RFC 9615 (actually, upon your suggestion
during IESG review :-) [1]). The current text says that you should always apply the consistency
checks specified here -- which includes the case of "Accept after Delay".
In this context, the cited paragraph is a non-normative reminder that the
preferred method is RFC 9615; consistency requirements apply regardless.
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/nns1_YDsvbVvopCS1W_7rP_uGsQ/
and these other things might be good alternatives. 9615 and epp are both
alternatives.
EPP has nothing to do with CDS consistency. Also, the child operator generally
doesn't speak EPP.
RFC 7344 is about updating DS records (where the old key signs the new
CDS/CDNSKEY RRset), whereas the cited example is about bootstrapping (where the
is no DS RRset yet).
But that case is already covered in the RFC dedicated to dnssec boostrap. It's
a fundamental security consideration section there.
[...]> I guess I am finding this draft mixes up with 9615 in odd ways, and find
that 2 of the 3 examples in the appendix are about what 9615 already fully
addresses.
I agree it is harmless, but I'm not sure repetition here instead of just
pointing to 9615 is useful.
The failure mode described in this part of the appendix is applicable when using "Accept after
Delay", and mitigated by applying a consistency check. RFC 9615 does not fully address the
"Accept after Delay" case.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
