IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Fri, 24 September 2021 13:02 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 51BEF3A27C2 for <dnsop@ietfa.amsl.com>; Fri, 24 Sep 2021 06:02:04 -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 47XdEKy9bSMO for <dnsop@ietfa.amsl.com>; Fri, 24 Sep 2021 06:01:58 -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 BEEED3A27C0 for <dnsop@ietf.org>; Fri, 24 Sep 2021 06:01:58 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4HGBxw07FqzF3G; Fri, 24 Sep 2021 15:01:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1632488516; bh=2YRPQIWXtHh6rAS8qWEYWHAUg7Jjle2oDUn73gCgpOQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=bA96E7iCLia964mPevNkZYe4l06w+0Wmy7OsB1F/Hw5WWRrYGuhvHCCelLrVOkrEc cDxwH7O/PE49nIOjIVFGBsERbz06up77dcCkd3nQ6Eo8vUeyn2RKyS1awpw07M3z8a wNEjvRchn6KNdF3HTo8qoUPTGmNRK3ppM2/AiNes=
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 MjIfbKSiSX_v; Fri, 24 Sep 2021 15:01:55 +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; Fri, 24 Sep 2021 15:01:54 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id ED4611015CB; Fri, 24 Sep 2021 09:01:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E8C491015CA; Fri, 24 Sep 2021 09:01:53 -0400 (EDT)
Date: Fri, 24 Sep 2021 09:01:53 -0400
From: Paul Wouters <paul@nohats.ca>
To: Matthijs Mekking <matthijs@pletterpet.nl>
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
In-Reply-To: <4289d849-e31b-824b-e80d-cde4afa2ab10@pletterpet.nl>
Message-ID: <1884f6f8-bf53-94aa-ef6c-f8cc8f33c15e@nohats.ca>
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> <4289d849-e31b-824b-e80d-cde4afa2ab10@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6MAguDzKyZ9cd1gKTUks_P7W7NY>
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 13:02:05 -0000

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

v2.23.0 | Report a Bug | By Email