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

[Paul Wouters <[e-mail]>]

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