[DNSOP] Re: [Technical Errata Reported] RFC6781 (6692)

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 <peter@desec.io> 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 <matthijs@pletterpet.nl
> <mailto:matthijs@pletterpet.nl>> 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
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/
> listinfo/dnsop>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/
> listinfo/dnsop>
>
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>
> --
> 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
>