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

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 24 September 2021 10:28 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 AAD753A22C1 for <dnsop@ietfa.amsl.com>; Fri, 24 Sep 2021 03:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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] 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 Y1G5v92-hQli for <dnsop@ietfa.amsl.com>; Fri, 24 Sep 2021 03:28:12 -0700 (PDT)
Received: from lb3-smtp-cloud9.xs4all.net (lb3-smtp-cloud9.xs4all.net [194.109.24.30]) (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 83FF23A22C0 for <dnsop@ietf.org>; Fri, 24 Sep 2021 03:28:11 -0700 (PDT)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by smtp-cloud9.xs4all.net with ESMTPSA id TiR2mhw1iMWY7TiR4mhsLh; Fri, 24 Sep 2021 12:28:08 +0200
To: Paul Wouters <paul@nohats.ca>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, tjw.ietf@gmail.com, rwilton@cisco.com, dnsop@ietf.org, benno@NLnetLabs.nl, suzworldwide@gmail.com, jarle.greipsland@norid.no
References: <20210922141813.933D3F40726@rfc-editor.org> <aff1b695-5f9c-369d-51b7-23ea4be020cc@nohats.ca> <53d91282-8df9-3afa-316c-9fc90b2fd3f1@pletterpet.nl> <b0f431b2-e612-abd4-a9b9-b04d7340b336@nohats.ca>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <4289d849-e31b-824b-e80d-cde4afa2ab10@pletterpet.nl>
Date: Fri, 24 Sep 2021 12:28:04 +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: <b0f431b2-e612-abd4-a9b9-b04d7340b336@nohats.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4xfNtx/sLhH7V4Ng1aBqVeHNpK5dT57GwNtA2izsOMonDe0uSq+6uMzAST8iIBsJ2eU1pdkkn/YXqmAm0sgVSsQenEJSXPai7q5wIrel7Fdk5XVpieVOUB c/Ixd1HgkpP/DAxLV1TJs2JpnkYCuBVPPfhNLcm4INWFfpYyZKF2DRx7sJFJezIMsyrk5fHLUtHiF0Uz8rRcat7O+OrOVWMkeaJB6oCYoKb/cR3XptYh+k4y urNqn5h3ucZXac84I2lksVIuArF+7ilMYbw77l0BVKA6PESm9XU3s9mTmkqq60tKkW0VzCVwvsUKMnFmHzwl/0UCYqewhm4cLeQ5da5wGgRZK1jYlgoOaQsT w01D/Ruk9LNDou2CQZnIrLqRkwTQUt2sZlnR2YusPa2PccG8+ZlmDP6Z0mC5w8Gp+Dx13zLFaM8UwVctBhR5RHfc6RL5Gt+HdNAn6cr19IRap9afZT4KVw0G y0PkA3q9hO0ciru6W8kpssDr8521OqRC7KQQwQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mPmCWqJe2iF3rG47N7V9nfLkwC4>
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: Fri, 24 Sep 2021 10:28:16 -0000

Paul,

On 23-09-2021 15:52, Paul Wouters wrote:
> 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.

See below.


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

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