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

Joe Abley <jabley@hopcount.ca> Mon, 31 January 2011 13:21 UTC

Return-Path: <jabley@hopcount.ca>
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 6E38A3A6BFE for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level:
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ByKlftOM5IEm for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:21:26 -0800 (PST)
Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id E6C7D3A6BF1 for <dnsext@ietf.org>; Mon, 31 Jan 2011 05:21:25 -0800 (PST)
Received: from [199.212.90.21] (helo=dh21.r2.owls.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <jabley@hopcount.ca>) id 1PjtoJ-000Nup-Ot; Mon, 31 Jan 2011 13:28:52 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <AANLkTikiqe2K4S-dNsyQZ-xp71J4bM11SsahwpxfDKCX@mail.gmail.com>
Date: Mon, 31 Jan 2011 08:24:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca>
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> <4D45DE93.9090508@vpnc.org> <AANLkTinbjRebooyqWMpZ2oTudruoDSGqgaXXr35WPYVH@mail.gmail.com> <AANLkTikiqe2K4S-dNsyQZ-xp71J4bM11SsahwpxfDKCX@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
X-Mailer: Apple Mail (2.1082)
X-SA-Exim-Connect-IP: 199.212.90.21
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: dnsext@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
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:21:27 -0000

On 2011-01-31, at 08:14, Phillip Hallam-Baker wrote:

> ICANN has reserved the right to roll the root and according to one post requires the ability to do so at 60 days notice.

Since we have a published DPS, let's refer to that rather than pulling numbers out of e-mail threads.

  https://www.iana.org/dnssec/icann-dps.txt


Joe

4.5.3.  Entity private key compromise procedures

4.5.3.1.  Key Signing Key compromise

   ICANN has established and maintains Emergency KSK roll-over
   procedures to ensure readiness for key compromise situations.

   Upon the suspected or known compromise of a Root Zone Key Signing
   Key, IKOS will assess the situation, develop an appropriate action
   plan, and implement the action plan with approval from the PMA and
   ICANN executive management.

   As part of the KSK emergency roll-over procedures, ICANN maintains
   the capability of being able to generate and publish an interim Trust
   Anchor within 48 hours.  In favorable circumstances, this interim
   Trust Anchor may be used to facilitate an orderly RFC 5011 [RFC5011]
   automatic KSK roll-over to a new and sanctioned Trust Anchor
   generated at a new scheduled key ceremony, held within reasonable
   time.

   ICANN will inform the community of any emergency as soon as possible
   using the channels stipulated in section 2.1.

4.5.3.2.  Key Signing Key loss

   If the private component of a Trust Anchor is permanently lost, the
   latest point in time where this loss is detected, will inevitably be
   at the key ceremony when it is supposed to be used.  At this point in
   time, the Root Zone Maintainer/ZSK Operator has signatures for at
   least 33 days (see 6.6) of independent operations.

   If possible, a new KSK will be generated at this key ceremony or
   another ceremony scheduled within 48 hours.  If ICANN is unable to
   accommodate the key ceremony, an interim KSK must be generated by
   ICANN and published as a Trust Anchor within the stipulated 48 hours.

   The community is then given a minimum of 30 days notice to add the
   new Trust Anchors to the validating resolvers before the DNSKEY RRset
   has to be re-signed with the new Trust Anchor.  Failure to update a
   validating resolver will render that resolver inoperable.

   ICANN will inform the community of any emergency as soon as possible
   using the channels stipulated in section 2.1.

   The old Trust Anchor will remain untouched in the key set for one 10
   days time slot (see section Section 6.6).  In the next consecutive
   time slot, the old Trust Anchor will be marked as revoked, and after
   this time slot the lost key is permanently removed.

4.5.3.3.  Zone Signing Key Compromise

   ICANN will support Root Zone Zone Signing Key emergency rollover in
   the case of RZ ZSK compromise while following VeriSign's procedural
   directions.  Refer to the Root Zone ZSK Operator's DPS for details.