Re: [DNSOP] CDS/CDNSKEY RRSet authentication

Mark Andrews <marka@isc.org> Sun, 30 July 2017 00:38 UTC

Return-Path: <marka@isc.org>
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 6D097131CF3 for <dnsop@ietfa.amsl.com>; Sat, 29 Jul 2017 17:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 CNRrRGe-snDt for <dnsop@ietfa.amsl.com>; Sat, 29 Jul 2017 17:38:39 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 AD73212420B for <dnsop@ietf.org>; Sat, 29 Jul 2017 17:38:39 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BB48D349DBD; Sun, 30 Jul 2017 00:38:35 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A33AC160045; Sun, 30 Jul 2017 00:38:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 92854160075; Sun, 30 Jul 2017 00:38:35 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bGfpmYUlQU06; Sun, 30 Jul 2017 00:38:35 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3F1CE160045; Sun, 30 Jul 2017 00:38:35 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EF6828069BE6; Sun, 30 Jul 2017 10:38:32 +1000 (AEST)
To: Tony Finch <dot@dotat.at>
Cc: dnsop@ietf.org
From: Mark Andrews <marka@isc.org>
References: <alpine.DEB.2.11.1707292141070.23659@grey.csi.cam.ac.uk>
In-reply-to: Your message of "Sat, 29 Jul 2017 22:00:53 +0100." <alpine.DEB.2.11.1707292141070.23659@grey.csi.cam.ac.uk>
Date: Sun, 30 Jul 2017 10:38:32 +1000
Message-Id: <20170730003832.EF6828069BE6@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ccqA4zwUwCdD1FY2JIMdBnG-t34>
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: Sun, 30 Jul 2017 00:38:41 -0000

In message <alpine.DEB.2.11.1707292141070.23659@grey.csi.cam.ac.uk>, Tony Finch
 writes:
> I think I have spotted a lacuna or possibly erratum in RFC 7344.
> 
> In section 4.1 bullet 2 it says:
> 
>    o  Signer: MUST be signed with a key that is represented in both the
>       current DNSKEY and DS RRsets, unless [unusual case]

It just means that signers that know about ksk/zsk have special rules
for cds and cdnskey.  This is from BIND's dnssec-signzone and causes
the cds and cdnskey rrsets to be signed with both ksk and zsk dnskeys.

                } else if (set->type == dns_rdatatype_cds ||
                           set->type == dns_rdatatype_cdnskey ||
                           iszsk(key)) {

> This allows a setup where
> 
> * the DNSKEY RRset contains a ZSK and a KSK
> 
> * the DNSKEY RRset is signed by the KSK (of course)
> 
> * the CDS and CDNSKEY RRsets are signed by the ZSK (weirdly)
> 
> * the parent contains DS records corresponding to both the KSK (of
>   course) and the ZSK (weirdly)
> 
> In this weird setup the ZSK's DS can't authenticate the delegation (per
> RFC 4035 section 5.2) but it does authenticate the CDS/CDNSKEY RRsets.
> 
> Is this intended?

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.
 
> Or was RFC 7344 supposed to say something like:
> 
>    o  Signer: MUST be signed with a DNSKEY RR that authenticates the
>       delegation as described in RFC 4035 section 5.2 or any subsequent
>       updates, unless [unusual case]
> 
> One particularly relevant update is RFC 4509 which has extra requirements
> about ignoring SHA-1 DS records if SHA-2 records are present. Should this
> check also apply to CDS / CDNSKEY RRsets?
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Portland, Plymouth: Cyclonic, mainly west or southwest, 5 to 7. Moderate or
> rough. Rain then showers. Moderate or poor, becoming good.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org