Paul,

On 23-09-2021 15:52, Paul Wouters wrote:
On Thu, 23 Sep 2021, Matthijs Mekking wrote:

You are referring to text that describes Figure 10.

The following text in Section 4.3.5.1 refers to the figure in Appendix D:

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only do the operators
   have to exchange public keys but they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double-Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.

I don't think that changes my reply regarding the corner case of needing
the RRSIG - but that would be a different errata from the one reported.
I would still be interested to hear from implementers on that corner
case.

See below.


...
 It states "combined with a Double-Signature KSK rollover". So the
 appendix tables does describe what it claims. Wether it is required
 to combine sharing public ZSK's with a Double-Signature KSK is
 another question, and based on some scribbling I think it is better
 to indeed include it:

 A clean cache resolver will get to the parent and obtain NS_A, DS_A and
 DS_B. It then goes to the child at A (because it did not get an NS_B)
 and gets the DNSKEY RRset from Child A. This contains only 1 KSK,
 DNSKEY_K_A. So it must use DS_A to confirm validation. After a while
 for other data in the zone, it might query for data on NS_B and get
 some data signed by DNSKEY_Z_B but the existing DNSKEY RRset covers
 that key, so there is no problem. Even if it needs to re-query for
 the DNSKEY RRset on NS_B and it only gets DNSKEY_K_B (and not
 DNSKEY_K_A), it could match the DNSKEY RRset to DS_B and it would
 be fine.

 What might be a corner case though, is if the first queried DNSEY RRset
 (from NS_A) has not yet expired - eg when it is being pre-fetched. At
 that point, the resolver getting the DNSKEY RRset for NS_B would not
 contain a valid key for the DNSKEY RRset of NS_B (DNSKEY_K_B is missing
 from the set on NS_A). It would be a bit implementation specific on what
 would happen (or perhaps this is specified in some DNSSEC RFC?). One
 implementation could decide that since the RRSIG fails, to re-validate
 the DNSKEY RRset using the parent DS RRset. But it could also assume
 it has a valid DNSKEY RRset and this new query is just missing the
 proper signature. So I believe it would be more robust to proceed as
 is specified in Appendix D.

First, I think you mean it would be more robust to proceed as is specified in Figure 10, right? The rollover that publishes both DNSKEYs of both providers in each version of the zone (Double-Signature KSK rollover).

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.


- Matthijs

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to