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

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