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

Matthijs Mekking <matthijs@pletterpet.nl> Thu, 23 September 2021 06:58 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 E7D8F3A23EA for <dnsop@ietfa.amsl.com>; Wed, 22 Sep 2021 23:58:59 -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 0GGQGmF6URM3 for <dnsop@ietfa.amsl.com>; Wed, 22 Sep 2021 23:58:55 -0700 (PDT)
Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 CE47D3A23E9 for <dnsop@ietf.org>; Wed, 22 Sep 2021 23:58:53 -0700 (PDT)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by smtp-cloud9.xs4all.net with ESMTPSA id TIgwmbherMWY7TIgymfY1s; Thu, 23 Sep 2021 08:58:49 +0200
To: Paul Wouters <paul@nohats.ca>, RFC Errata System <rfc-editor@rfc-editor.org>
Cc: olaf@nlnetlabs.nl, tjw.ietf@gmail.com, matthijs@nlnetlabs.nl, rwilton@cisco.com, dnsop@ietf.org, benno@NLnetLabs.nl, suzworldwide@gmail.com, miek.gieben@sidn.nl, jarle.greipsland@norid.no
References: <20210922141813.933D3F40726@rfc-editor.org> <aff1b695-5f9c-369d-51b7-23ea4be020cc@nohats.ca>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <53d91282-8df9-3afa-316c-9fc90b2fd3f1@pletterpet.nl>
Date: Thu, 23 Sep 2021 08:58:46 +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: <aff1b695-5f9c-369d-51b7-23ea4be020cc@nohats.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4xfFkXuaC3rpFiUcK+NYUED00Vole0zXQkpoU2OTYtLEPejpv2dkPLrZw48fxT2VynVBIlvmDBHF+GxJQT2+hWVJrMXQErwwEz2It1dMBrOAPfsinudnjU NOLBqXa2lPwGxBoSNg3LGZR2qGR0FcIpFuDaiCTy0XDeosatR5GQYtxk/+ztlpBU3gL+tf8RVEIQB9q8pEtoFtxszi/itz4NqqVxpjYXP2Vd0Cn0xXX2Pcrd gzSPd9jhHfuoMTlhQXep2i8aXrXJd6UCrpeNIm/KjiEdF0+H+KlqTRv9FjWJ6Si8ge5wAj2/k7wV+LffTPjVovNl3FUkIh3NkA24ZfatMgh61yoNeStxU1vU wW0A45RL9FeAZzQiJde1huArkJtdydaSKEYBymNJ99DQuWQ53cB7vljbw3tkrq8Ej5+ja5J9RQ75hFk21WjLTSm7T0vZK5hT/8hy5f0e0dJxHFev/ELBpo4l 6rrHQ95D+VWqA9adwn8sxvKw0RTvQIrUx7s0asF/GGvSNWBK+pBzvkIf/owL/XUoE5nbqtdB2ZOrUHngVYTpufCli9HWBZwbHPa2Cw64oq2Vie5azZt5NjMb YW0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QtWBxGdQaYE6GfPUvaAJfSyoGpE>
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: Thu, 23 Sep 2021 06:59:00 -0000

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:
> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop