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

Matthijs Mekking <matthijs@pletterpet.nl> Wed, 22 September 2021 14:21 UTC

Return-Path: <matthijs@pletterpet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136283A23C5 for <dnsop@ietfa.amsl.com>; Wed, 22 Sep 2021 07:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnIzuWud9g2s for <dnsop@ietfa.amsl.com>; Wed, 22 Sep 2021 07:21:47 -0700 (PDT)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011C33A23BF for <dnsop@ietf.org>; Wed, 22 Sep 2021 07:21:45 -0700 (PDT)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by smtp-cloud8.xs4all.net with ESMTPSA id T381mAtSEeJ0cT382m4ur3; Wed, 22 Sep 2021 16:21:43 +0200
To: dnsop@ietf.org
References: <20210922141813.933D3F40726@rfc-editor.org>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <a6007daf-42ff-60ff-5898-3f48912be38c@pletterpet.nl>
Date: Wed, 22 Sep 2021 16:21:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <20210922141813.933D3F40726@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfCOaCzZG3LQ23gOgvSRX1KmbJO+HWBzaKjrxGKkgcao1aSC7mhfo8wtOiTluAa1YV2VkyiKGV23zUrL22tiC4JOqAf1Cfwrg5J0LzWslXNIPOkvuXXI6 EtzPTke5B2vCNEjHIgbupQ2l0jNpU2ftahfiQVqeBwdvD9DJKwkOmuS+jE9/5buBFhFQTUR3jqPmi/W5fAomZx8u5UmUNh532ilbvmAbthzYIUUaAYgAVEeN w7HxXiQb1LVp/A1auMQsuYEehPsdZV9AYUB8KDXyCjO75GHWlNVrzz9xykzfXp2N
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ox0fFUw-NMa-G9jr42BpUpZ-fak>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC6781 (6692)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2021 14:21:52 -0000

I believe this errata is correct.

On 22-09-2021 16:18, RFC Errata System wrote:
> 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 <jarle.greipsland@norid.no>
> 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>