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
- [DNSOP] CDS/CDNSKEY RRSet authentication Tony Finch
- Re: [DNSOP] CDS/CDNSKEY RRSet authentication Mark Andrews
- Re: [DNSOP] CDS/CDNSKEY RRSet consistency Tony Finch
- Re: [DNSOP] CDS/CDNSKEY RRSet authentication Richard Lamb
- Re: [DNSOP] CDS/CDNSKEY RRSet authentication Tony Finch