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

Paul Wouters <paul@nohats.ca> Thu, 23 September 2021 13:52 UTC

Return-Path: <paul@nohats.ca>
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 256D03A1E2F for <dnsop@ietfa.amsl.com>; Thu, 23 Sep 2021 06:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 2EcQoStwNKvY for <dnsop@ietfa.amsl.com>; Thu, 23 Sep 2021 06:52:47 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 EA5FE3A30B7 for <dnsop@ietf.org>; Thu, 23 Sep 2021 06:52:46 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4HFc6z0QTJzCyk; Thu, 23 Sep 2021 15:52:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1632405163; bh=bHLx04N4sjNtT1Zg1upL1jcsjA6A3qXQdDm8Y2Up2kI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SNJGDwfvTxI+JR95WstVozrfl4Ofh1pwKI9pDDlOogwVf7HLxPH/8F8i4eRQnYk0g MIG01uKstWGDZrv3iuxjTi6RdiPATJEZ5pdEGUmm1r7kx5FIqAYmd2s3Uf2QbKHvSQ CO1JusoPZfY31P0wFKY2wSJzIhuoHGjed+YmT6B0=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TIukDY4MJ9Vi; Thu, 23 Sep 2021 15:52:41 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 23 Sep 2021 15:52:41 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1B97AFFBE8; Thu, 23 Sep 2021 09:52:40 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 18267FFBE7; Thu, 23 Sep 2021 09:52:40 -0400 (EDT)
Date: Thu, 23 Sep 2021 09:52:40 -0400
From: Paul Wouters <paul@nohats.ca>
To: Matthijs Mekking <matthijs@pletterpet.nl>
cc: RFC Errata System <rfc-editor@rfc-editor.org>, 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
In-Reply-To: <53d91282-8df9-3afa-316c-9fc90b2fd3f1@pletterpet.nl>
Message-ID: <b0f431b2-e612-abd4-a9b9-b04d7340b336@nohats.ca>
References: <20210922141813.933D3F40726@rfc-editor.org> <aff1b695-5f9c-369d-51b7-23ea4be020cc@nohats.ca> <53d91282-8df9-3afa-316c-9fc90b2fd3f1@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7GroLJGK9Z2YAqJ4ETNDvKJjd9o>
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 13:52:52 -0000

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