Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

Antoin Verschuren <antoin.verschuren@sidn.nl> Tue, 09 July 2013 09:57 UTC

Return-Path: <Antoin.Verschuren@sidn.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 AB16E21F9F81 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2013 02:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.607
X-Spam-Level:
X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlfrmbbjSLA1 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2013 02:57:06 -0700 (PDT)
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6321F9F8D for <dnsop@ietf.org>; Tue, 9 Jul 2013 02:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=CUpLxCRl1vw092LHH77+SDxwVJFaVwvwWElrlQlGMpg=; b=cJxMr9F/qnueDyii/CBLfD6/cy7jrXg81cevWfMdd+9+aLHoqJ/S+F7YkjP0mkj9LhKfB3dqzuTcyLkYDTAwECKPiLxl40I4gueKtiSRl+BOr0ixhIVGGK+YwaQqqFAo2fuvbNLcBW9Sta3KqSyRB1XHE9Jh0I2Hw5e21BQbzTE=
Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r699ul5h024269-r699ul5j024269 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 9 Jul 2013 11:56:47 +0200
Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn02.SIDN.local (192.168.2.74) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 9 Jul 2013 11:56:42 +0200
Received: from [94.198.152.214] (94.198.152.214) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 9 Jul 2013 11:56:48 +0200
Message-ID: <51DBDE5E.9070805@sidn.nl>
Date: Tue, 09 Jul 2013 11:56:46 +0200
From: Antoin Verschuren <antoin.verschuren@sidn.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: Patrik Fältström <paf@frobbit.se>
References: <20130617165829.2638.88322.idtracker@ietfa.amsl.com> <DD7454F5-6B16-4EBA-A380-C51E2302E5E9@kumari.net> <alpine.LFD.2.10.1306171417150.18979@bofh.nohats.ca> <0lsj0b2kk5.fsf@wjh.hardakers.net> <51C96B62.9030401@nlnetlabs.nl> <2350A43B-088E-4BEA-9317-98B8372C74BE@ogud.com> <51D18336.5010401@nlnetlabs.nl> <9245734C-D614-41C4-B2FC-C39D6DAAA5C3@ogud.com> <8E20305A-4B51-4714-B339-0C5703E75828@sinodun.com> <A82661B1-414B-435C-B359-53BC0F17EEA3@ogud.com> <33496ED6-4D88-485B-8369-566B2A1FC7C0@frobbit.se> <51DBBFBD.5020300@sidn.nl> <791FD3EC-91F6-448E-80D7-DC607A02AA2B@frobbit.se>
In-Reply-To: <791FD3EC-91F6-448E-80D7-DC607A02AA2B@frobbit.se>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [94.198.152.214]
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 09 Jul 2013 09:57:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 09-07-13 10:05, Patrik Fältström schreef:
> 
> The registry get an EPP update via a secure channel to change the
> NS. They can at that time (before the new zone is published) issue
> queries for CDS at the suggested new target of the NS, and if the
> CDS exists there they can fetch the CDS, see if key material
> changed, and incorporate the data in the zone that is to be
> published.

That CDS record will not validate at that point in time, so it will
always be ignored.
The pre-requisite for CDS is that the record can be validated, and the
new zone is not yet in the chain of trust if the DNSKEY RRset that is
present in the validating resolver does not contain the key by which
the CDS record in the new zone is signed.

You could do a theoretical validation of that record with the assumed
future state of the zone and delegation at the parent, but all
validating resolvers in the real world will have a DNSKEY RRset cached
from the past, and are not aware of any future change until after it
has happened. So during the DNSKEY TTL all records that should
validate against the DNSKEY RRset will have a chance of being bogus,
depending on from which zone the signatures come and which DNSKEY
RRset is cached..
Unless you have pre-published a DNSKEY RRset that contains the ZSK's
of both zones, so both signatures validate.

But then there is no need to query the CDS record, because you cannot
do a simultaneous second key rollover during a key maintainer change.
You'll have to wait at least one child NS TTL after the NS change at
the parent until it's safe to remove the old key and do another key
rollover, so querying CDS immediately after changing the NS at the
parent will always result in zero changes if you want your zone to work.


- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: antoin.verschuren@sidn.nl
XMPP: antoin.verschuren@jabber.sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJR295eAAoJEDqHrM883AgnFC4IANZXG6Rl8HB3U6U7UZS3URxf
ham8o3+5hi9nx1s1KN4zljBWjnL0O0N2jBK+keSWLHLmmWzinFMjtHEv4RFaE9Ho
++jC0kZT2Z0Re65A2ZOh9lewpSvzBul9axcrD10w/yehVJhm5L4mAOhoL29dsegv
PMsHpqDy1DJ0MvWrx+wdzGKTCG0S79SAbUedt0kLPt8tH0FFMAFUON1yFj3cYp2W
ovpWGN1R0ex7g66CCSBWcx5otp8GJx1wIs1pra1xt3QmhOHTxKzGkuRIUjRRpMf7
AoogKu6i1LnxFVwGmlZab2Gebkx0g5aY3whrxZ65g30Wn1kPcFS1QBeHrQO+vDI=
=A5ER
-----END PGP SIGNATURE-----