Awesome, thank you! I marked it as Verified and linked to this thread for tracking / additional info.
W On Mon, Jul 08, 2024 at 6:22 PM, Peter Thomassen <[email protected]> wrote: > Hi Warren, > > tl;dr: The erratum is correct, and I think can be verified. > > The situation described in the second-to-last paragraph of RFC 6781 > Section 4.3.5.1 (and illustrated in Appendix D) amounts to > > - adding operator B as a multi-signing party according to RFC 8901 Model, > - removing operator A. > > The delegation goes directly from NS_A to NS_B, whereas a permanent > multi-signer setup would have both NS_A and NS_B in the delegation. > Otherwise, the above is identical to a Model 2 multi-signer configuration. > > To evaluate the erratum, it thus helps to think about multi-signer > transitions. It turns out these have been analyzed in detail. For example, > see page 2 of the IETF 115 DNSOP presentation on Multi-Signer Key Exchange > [1], which says: > > DNSKEY responses must contain all keys a validating resolver may need for > validation [...] > (RRSIG is always from the same provider [as the DNSKEY RRset]) > > Perhaps an example helps. If you have two providers, a resolver might > fetch the DNSKEY RRset from provider A and some other RRset (e.g., www IN > A) from provider B. (In multi-signer, this happens routinely, and in RFC > 6781 Section 4.3.5.1 it happens when the delegation switches between the > two fetches.) -- Now, what's important is that, at each provider, > > 1.) the DNSKEY RRset has either provider's ZSK, so that one can validate > the "www IN A" RRset with it, regardless of which providers the DNSKEY and > A RRset were fetched from; > > 2.) the DNKSEY RRset itself needs to be validated, which works if it is > signed with a key that is represented in the DS RRset. In the situation at > hand, there DS records for *both* provider's KSK, so *either one* can be > used to validate the DNSKEY RRset. It therefore suffices if each provider > serves their own DNSKEY RRSIG. > > They only need import each other's ZSKs, but not exchange KSKs or RRSIGs. > > This is exactly the point of the erratum. > > Best, > Peter > > [1]: https://datatracker.ietf.org/meeting/115/materials/ > slides-115-dnsop-multi-signer-key-exchange-mske-00.pdf > > On 6/27/24 16:46, Warren Kumari wrote: > > Hi there WG, > > I am trying to go through and clean up all open Operations Errata. > > I would really appreciate some input / advice from the WG on what I should > do here — I've read and reread the thread and the document, and cannot > figure out if this Errata is correct or not…. > > I'm tempted to mark this as Hold for Document Update, but I'm not sure if > that is best. > > Errata: https://www.rfc-editor.org/errata/eid6692 <https://www.rfc-editor. > org/errata/eid6692> RFC: RFC6781 - "DNSSEC Operational Practices, Version > 2" <https://datatracker.ietf.org/doc/rfc6781/> > > Types of Errata: https://www.rfc-editor.org/errata-definitions/ <https:// > www.rfc-editor.org/errata-definitions/> > > W > > On Fri, Sep 24, 2021 at 3:35 PM, Matthijs Mekking <[email protected] > <mailto:[email protected]>> wrote: > > I am going to assume that the DNSKEY of this zone is not a trust anchor. > > So it is going to use the DS RRset, not a cached DNSKEY RRset, to > authenticate the child zone's apex DNSKEY RRset (the one from the > response). Then from RFC 4035: > > o The matching DNSKEY RR in the child zone has the Zone Flag bit set, the > corresponding private key has signed the child zone's apex DNSKEY RRset, > and the resulting RRSIG RR authenticates the child zone's apex DNSKEY > RRset. > > I read this as the cached DNSKEY RRset does not come into play when > validating the DNSKEY RRset from the response, and any implementation that > does otherwise is not compliant. > > - Matthijs > > On 24-09-2021 15:01, Paul Wouters wrote: > > On Fri, 24 Sep 2021, Matthijs Mekking wrote: > > Second, I believe the corner case you mentioned is for Figure 15 (the one > in Appendix D), and I don't understand the scenario you are describing. > What do you mean with "the resolver getting the DNKSEY RRset for NS_B would > not contain a valid key for the DNSKEY RRset of NS_B". I think the resolver > would get a new DNSKEY RRset with a pre-fetch (or if the DNSKEY RRset was > expired from cache) and that would be validated with the DNSKEY from the > response. > > If it has a valid unexpired DNSKEY RRset, and a resolver fetches that > DNSKEY RRset again, will it use the cached DNSKEY RRset or the DNSKEY RRset > from the fetched record set to validate the signature against the cached DS > RRset ? Or is this implementation specific? > > Paul > > _______________________________________________ > DNSOP mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/ > listinfo/dnsop> > > _______________________________________________ > DNSOP mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/ > listinfo/dnsop> > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffhäuserstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
