Re: [DNSOP] CDS/CDNSKEY RRSet authentication

Tony Finch <dot@dotat.at> Wed, 02 August 2017 14:41 UTC

Return-Path: <dot@dotat.at>
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 01048131C34 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 07:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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 BwMCE2BDpEbr for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 07:41:45 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D0F1F1274A5 for <dnsop@ietf.org>; Wed, 2 Aug 2017 07:41:44 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:44192) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dcuqE-000ymF-fr (Exim 4.89) (return-path <dot@dotat.at>); Wed, 02 Aug 2017 15:41:42 +0100
Date: Wed, 02 Aug 2017 15:41:42 +0100
From: Tony Finch <dot@dotat.at>
To: Mark Andrews <marka@isc.org>
cc: dnsop@ietf.org
In-Reply-To: <20170730003832.EF6828069BE6@rock.dv.isc.org>
Message-ID: <alpine.DEB.2.11.1708021528270.1665@grey.csi.cam.ac.uk>
References: <alpine.DEB.2.11.1707292141070.23659@grey.csi.cam.ac.uk> <20170730003832.EF6828069BE6@rock.dv.isc.org>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d5zXk0VX5k94G7y9y05inEgyoLI>
Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 02 Aug 2017 14:41:46 -0000

Mark Andrews <marka@isc.org> wrote:
>
> The purpose was for the CDS/CDNSKEY tools to not have to fetch the
> current DNSKEY RRset to be able to validate the records provided they
> have a current KSK.

Oh, that's neat, thanks!

Having thought about it a bit more I understand why the draft says what it
does and why that makes sense.

It's difficult that KSK can mean four different and not necessarily
congruent things:

 1. keys with the SEP bit set

 2. keys that sign the DNSKEY RRset

 3. keys with digests in the DS RRset

 4. keys that are trust anchors

My understanding is that for a validator the SEP bit is irrelevant.

For 2 and 3 the distinction I needed is that the DS keys are the ones
authenticated by the parent; the signing of the DNSKEY RRset allows the
child to authenticate additional keys (i.e. ZSKs). But from the parent's
point of view what matters is that the RRset as a whole is signed by a
parentally authenticated key.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Tyne, Dogger, Fisher, German Bight: South or southwest 3 or 4, increasing 5 or
6, occasionally 7 later. Slight becoming moderate. Rain then showers. Moderate
or good.