On Tue, Nov 18, 2025 at 12:32 PM Peter Thomassen <[email protected]> wrote:
> Right. I've changed the text as follows (to be submitted after the > telechat, so happy to apply more changes): > > OLD > Readers are expected to be familiar with DNSSEC, including [RFC4033], > [RFC4034], [RFC4035], [RFC7344], and [RFC7477], and may refer to > [RFC6781] and [RFC8901] for an overview of DNSSEC operational > practices. > > NEW > Readers are expected to be familiar with DNSSEC [RFC9364], in > particular [RFC4033], [RFC4034], [RFC4035], [RFC7344], and [RFC7477]. > For an overview of related operational practices, refer to [RFC6781] > and [RFC8901]. > > Rationale: > - Besides referencing DNSSEC as a whole, I think it's worthwhile pointing > the reader to the specific bits that are directly related to this document. > I disagree, but as I said, it is not a blocking issue for me. > - The "operational practices" phrase was introduced after a review by Med. > Sure. > > > 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 and these other things might be good alternatives. 9615 and epp are both alternatives. > I'll be happy to add that a provisioning protocol like EPP can also be > used (not only for DS bootstrapping, but also for DS updates as well as NS > updates), but that would have to go elsewhere in that document. OTOH, I > don't think it's needed as the doc is specifically about clarifying aspects > of CDS/CDNSKEY and CSYNC. > I think it belongs in this section for the reasons you cite :) > > who may then inadvertently break the chain of trust by prematurely > removing > > a DNSKEY still referenced by a (stale) CDS/CDNSKEY RRset. > > > > I am confused here. How can one "prematurely" remove a DNSKEY that is > > referenced by a (stale) CDS/CDNSKEY ?? I think you mean "accidentally" > remove a > > newly introduced DNSKEY that is not referenced by a (stale) CDS/CDNSKEY? > > No. Let's say you want to roll to a different algorithm, say from alg 8 to > 13, and the parent processes CDNSKEY after 1 day maximum. > > Steps (between each, wait for TTL etc; signature addition/removal not > spelled out in detail): > > step 0: > - DNSKEY is KSK_8 > - CDNSKEY is KSK_8 > > [DS record points to KSK_8] > > step 1: > - DNSKEY is KSK_8 and KSK_13 > - CDNSKEY is KSK_8 > > step 2: > - DNSKEY is KSK_8 and KSK_13 > - CDNSKEY is KSK_8 and KSK_13 > > [after a day, the parent will have updated DS record to point to KSK_8 and > KSK_13] > > step 3: > - DNSKEY is KSK_8 and KSK_13 > - CDNSKEY is KSK_13 > > [wait for another day] > > step 4: > - DNSKEY is KSK_13 > - CDNSKEY is KSK_13 > > This is the normal process. > > However, if one secondary is lagging, and the parent queries only that > secondary (not enforcing consistency), then the parent may only see the > CDNSKEY RRset from step 2, not from step 3, and not actually update the DS > record. But that is the same as the parent happens to check just before you updated the (hidden) primary. Eg nothing has changed yet. In itself, the "no action by parent" is expected to happen a number of times without ill side effects. > If the child does not notice the stale secondary and orchestrates things > only by timing, it may remove KSK_8 from the DNSKEY RRset on the non-stale > secondary (step 4), which is then in algorithm mismatch with the DS RRset. > A child should not update its DNSKEY RRset without checking the parent's DS have updated (and of course, it should check all parent's nameservers for consistency there :) That is, I don't think this case is a "parental operational issue". It is a child operational issue. > > This is described by "inadvertently break the chain of trust by > prematurely removinga DNSKEY still referenced by a (stale) CDS/CDNSKEY > RRset." > > Similar issues can be constructed when only rolling a key (not algorithm), > where the stale secondary remains in step 0 or 1, i.e. the DS RRset does > not get updated but the child proceeds with the rollover nevertheless. > > Now you can of course say that the child should not proceed if it doesn't > see the correct DS record. Exactly :) > Note, however, that in the case of the algorithm rollover, the child > *does* observe the correct DS record. (And also, the guidance is for how > parents can prevent breakage, even when the child makes a mistake.) > But I don't think this appendix claim is in scope of what parents should do. It is worth mentioning for sure though. > > In particular, the rogue nameserver can publish CDS/CDNSKEY records. > If > > those are processed by the parent without ensuring consistency with > other > > authoritative nameservers, the delegation will, with some patience, > get > > secured with the attacker's DNSSEC keys. > > > > Note as per RFC7344 this cannot happen. CDS/CDNSKEY records MUST validate > > before being processed, or covered via an alternative method: > > 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. > > > RFC9516 updates this but also requires another signal in that case: > > https://datatracker.ietf.org/doc/html/rfc9615#signaling > > Correct. However, the attacker can use the same signaling when the control > the hijacked nameserver (such as after its domain registration expired). > This will only be detected if the parent looks for the signal under all > nameserver hostnames, not just one. > > For this very reason, RFC 9615 requires parents to look under all > nameserver hostnames (Section 4.2 step 3), which is exactly the consistency > check this draft spells out in more general terms. > 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. Again, none of these are blocking issues for me. The WG can resolve these as it sees fit. Paul
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
