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

[Paul Wouters <[e-mail]>]

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.

Paul

> Best regards,
>
> Matthijs
>
> On 23-09-2021 05:08, Paul Wouters wrote:
>>  On Wed, 22 Sep 2021, RFC Errata System wrote:
>>
>>>  Figure 15 in Appendix D is depicting the phases of a double DS KSK
>>>  rollover operator change.  One rationale for applying this approach is to
>>>  avoid the exchange of signatures (RRSIGs) between operators, and limit
>>>  exchanges to the public parts of the ZSKs in use.  In the pre-publish
>>>  phase in the figure, it is shown that Child A publishes a signature over
>>>  the DNSKEY RRset generated by Child B's KSK, and that Child B publishes a
>>>  signature over the DNSKEY RRset generated by Child A's KSK.  This is
>>>  contrary to the rationale given for this method, and also not required,
>>>  since the pre-published double DS RRs at the parent zone should enable a
>>>  validator to validate the signature generated by any of the two KSKs in
>>>  use, thus one RRSIG RR for the DNSKEY RRset is sufficient at each child. 
>>>  Therefore, the RRSIG_K_B(DNSKEY) RR should be removed from Child A, and
>>>  the RRSIG_K_A(DNSKEY) should be removed from Child B.
>>
>>  I am not sure you are correct. Your description is slightly different from
>>  the Section 4.3.5.1 this Appendix D belongs to:
>>
>>
>>      In this environment, the change could be made with a Pre-Publish ZSK
>>      rollover, whereby the losing operator pre-publishes the ZSK of the
>>      gaining operator, combined with a Double-Signature KSK rollover where
>>      the two registrars exchange public keys and independently generate a
>>      signature over those key sets that they combine and both publish in
>>      their copy of the zone.
>>
>>
>>  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.
>>
>>  Paul
>>
>>  _______________________________________________
>>  DNSOP mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/dnsop
>
>