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 <matth...@pletterpet.nl
<mailto:matth...@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-le...@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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
