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

From: RFC Errata System <[email-masked]>
Date: Wed, 22 Sep 2021 07:18:13 -0700 (PDT)

The following errata report has been submitted for RFC6781,
"DNSSEC Operational Practices, Version 2".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6692

--------------------------------------
Type: Technical
Reported by: Jarle Fredrik Greipsland <[email-masked]>

Section: Appendix D

Original Text
-------------
    ------------------------------------------------------------
    new DS             |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A DS_B                       DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
                            RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

Corrected Text
--------------
    ------------------------------------------------------------
    new DS             |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A DS_B                       DS_A DS_B
    ------------------------------------------------------------
    Child at A:            Child at A:        Child at B:
     SOA_A0                 SOA_A1             SOA_B0
     RRSIG_Z_A(SOA)         RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)

     NS_A                   NS_A               NS_B
     RRSIG_Z_A(NS)          NS_B               RRSIG_Z_B(NS)
                            RRSIG_Z_A(NS)

     DNSKEY_Z_A             DNSKEY_Z_A         DNSKEY_Z_A
                            DNSKEY_Z_B         DNSKEY_Z_B
     DNSKEY_K_A             DNSKEY_K_A         DNSKEY_K_B
     RRSIG_K_A(DNSKEY)      RRSIG_K_A(DNSKEY)  RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

Notes
-----
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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--------------------------------------
Title               : DNSSEC Operational Practices, Version 2
Publication Date    : December 2012
Author(s)           : O. Kolkman, W. Mekking, R. Gieben
Category            : INFORMATIONAL
Source              : Domain Name System Operations
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 22 Sep 2021 16:21:41 +0200

I believe this errata is correct.

On 22-09-2021 16:18, RFC Errata System wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Sep 2021 23:08:35 -0400 (EDT)

> 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 operat…

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

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 23 Sep 2021 08:58:46 +0200

Paul,

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.

Best regards,

Matthijs

On 23-09-2021 05:08, Paul Wouters 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.
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Sep 2021 09:52:40 -0400 (EDT)

>    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

>>>  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.
>>

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 24 Sep 2021 12:28:04 +0200

Paul,

> I would still be interested to hear from implementers on that corner

See below.

...
>>>  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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Sep 2021 09:01:53 -0400 (EDT)

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

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 24 Sep 2021 16:35:43 +0200

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:
>> 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.
>