Re: [dnsext] historal root keys for upgrade path?

"W.C.A. Wijngaards" <wouter@NLnetLabs.nl> Mon, 31 January 2011 13:06 UTC

Return-Path: <wouter@nlnetlabs.nl>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377D03A6C08 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:06:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nniwcYZeZmv7 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:06:47 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id D2DB43A6BEB for <dnsext@ietf.org>; Mon, 31 Jan 2011 05:06:46 -0800 (PST)
Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p0VD9vOR056209 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Mon, 31 Jan 2011 14:09:59 +0100 (CET) (envelope-from wouter@nlnetlabs.nl)
Message-ID: <4D46B4A5.1090502@nlnetlabs.nl>
Date: Mon, 31 Jan 2011 14:09:57 +0100
From: "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <alpine.LFD.1.10.1101251250040.30991@newtla.xelerance.com> <17A80F45-52CB-43F6-BD4A-3488821F6933@hopcount.ca> <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org> <583A62B0-0DBF-469A-AF8A-B81DEDD1E7E2@dotat.at> <86B1D38A-C274-4335-B30E-3C5C0DF05C38@hopcount.ca> <alpine.LSU.2.00.1101311014030.5244@hermes-1.csi.cam.ac.uk> <C6218FC5-0261-4763-8DF3-019638A8E612@hopcount.ca>
In-Reply-To: <C6218FC5-0261-4763-8DF3-019638A8E612@hopcount.ca>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 31 Jan 2011 14:09:59 +0100 (CET)
Subject: Re: [dnsext] historal root keys for upgrade path?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 13:06:48 -0000

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

Hi Joe,

On 01/31/2011 01:14 PM, Joe Abley wrote:
> RFC 5011 is a mechanism for scheduled key rollovers. There is always
> the possibility that emergency key rollovers will happen, and that
> 5011 semantics (in particular the 30-day dual-publish window) might
> not be followed.

The approaches under discussion that I made rely on a 30-day
dual-publish window, the trust-history draft and the unbound-anchor
tool.  Because the approaches extend the 5011 mechanism with downtime
compensation.  You can see from the 5011 state why it is failing, and
30-days downtime caused it.  Increased speed for the bootstrap mechanism
would make that bootstrap mechanism less safe (because it can be used to
circumvent the 30-day timer in 5011), hence I chose to wait until 5011
is known to fail (30-days passed) so that this 'add-on' to 5011 would
not lower security.  Thus a fast rollover would break those deployments:
both 5011 and the bootstrap mechanism will fail, and the failure mode is
that the key is unchanged.  This is a feature, ... if you want software
deployed that does something else, then, it is good to have this
discussion :-)

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1GtKUACgkQkDLqNwOhpPjctQCfTAqOmPcmtXVmNkShmpzZ0Xao
3QUAnjCWf2NM751Q3GhsxAbRLWY/Yh5s
=OlbS
-----END PGP SIGNATURE-----