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

Phillip Hallam-Baker <hallam@gmail.com> Tue, 01 February 2011 05:56 UTC

Return-Path: <hallam@gmail.com>
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 134643A68B8 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 21:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.474
X-Spam-Level:
X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 u3foSqM4QAaC for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 21:56:42 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 27B643A687B for <dnsext@ietf.org>; Mon, 31 Jan 2011 21:56:40 -0800 (PST)
Received: by gyd12 with SMTP id 12so2668743gyd.31 for <dnsext@ietf.org>; Mon, 31 Jan 2011 21:59:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7DfmFz5PgL9hmMk3Dk7H/id7onVW9a/t7VMUPPv/6xU=; b=Kz0yyuhWeJ4iZV4H7Wva4zyIMlL4d5Lvf57S2rLhL37j1VnmDfmAynhzmpIQHZXvlE yIRWFExrlPhZDE6zgBBTIG36q1b3oxT7SjbASn+42hz8QZURzC32mLut5RQOwboV/tsq X16udyicGp0TkLrvtkjLbTd/twMOHm4wuqAF4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vMOEG8g8u9bAT7OJ+l55m7mPyP33X1VMUiykUSziAa2X9BORE3ixO5u1+q92j6m6PN 3PJibiPDE733Hmw9IWtVffBbZLubhxhM1Ao67GL0iVNFUu+oWgwvdlFJ8Q9Z5Wp2Dhrd kb91ouHEn7fhBV4gwxhO09b/lczhHP4/avP8U=
MIME-Version: 1.0
Received: by 10.100.48.3 with SMTP id v3mr4658739anv.154.1296539995763; Mon, 31 Jan 2011 21:59:55 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 21:59:55 -0800 (PST)
In-Reply-To: <AANLkTinq+F3AfXROavDW5YGeZ2zVeqW4Oc0jSkWmN8Ss@mail.gmail.com>
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> <4C747F08-A9E8-46E6-AE76-0A999A16D276@hopcount.ca> <AANLkTinOtx88vK3mz-w=uw1CnsKwm=c-nTDOsj=5JAPY@mail.gmail.com> <AANLkTiksER2SYPLiwy6uta3UBvbrEj0mDVOJnKSV-fbV@mail.gmail.com> <AANLkTinq+F3AfXROavDW5YGeZ2zVeqW4Oc0jSkWmN8Ss@mail.gmail.com>
Date: Tue, 01 Feb 2011 00:59:55 -0500
Message-ID: <AANLkTi=R4dB_c4Dny5zY6fMMBi1rtewJpVZ4CkoK_w+C@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary="0016e645b8c4e27720049b323d57"
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: Tue, 01 Feb 2011 05:56:44 -0000

On Tue, Feb 1, 2011 at 12:02 AM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

> On Mon, Jan 31, 2011 at 3:23 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> >
> > On Mon, Jan 31, 2011 at 1:22 PM, Brian Dickson
> > <brian.peter.dickson@gmail.com> wrote:
> >> The simplest bootstrap method would be to have a series of BSK
> >> (bootstrap keys), created on a periodic basis (every N years), and
> >> used as follows:
> >
> > If a compromise has occurred then the first thing to ask would be why.
> > There are only three places where a compromise can logically occur - in
> the
> > cryptographic algorithm, in the cryptographic hardware manufacturer or in
> > ICANN,
> > If its the algorithm then the whole series of BSKs is compromised.
>
> I think it is helpful to use as explicit a form of language as
> necessary, to clearly communicate ideas.
>
> So, when I ask you to clarify this into particulars, it is with the
> intent of understanding what you meant.
>
> "If a compromise has occurred" - a compromise of what, exactly, are
> you talking about?
>
> It could be that there has been a theoretical weakness in the
> algorithm, which makes it slightly more feasible to break, but that
> the root zone key's private parts have not been exposed.
>
> In which case, this is "theoretically weak".
>

This is of course possible, and something easily cured at the sub-root
level.

It is not possible to cure it at the root level unless you move to a
different key strength or more likely given the way RSA strength goes with
key size, a whole new algorithm.


On the other hand, it could be that the root zone key has had its
> private parts found, in which case the term "compromised" has the very
> real, concrete meaning in that someone has directly compromised its
> security.
>

This could not happen without the cryptographic hardware being faulty or
physically compromised or the design of the system being at fault.

Competently designed HSMs do not allow their keys to be exported to just any
HSM. There is a cryptographic protocol that governs transfer of keys from
one to another.

It should take multiple failures before it was even possible to attempt such
an attack.



> In both cases, the impact on another key, which is neither dependent,
> nor whose security depends on, the root zone key, is non-existent,
> other than that it implies that the other key is equally
> "theoretically weak".
>

The whole purpose of high security root key management is to ensure that
compromise is not possible without a major systemic failure.

Since both keys are managed under the same practices, a systemic fault that
affects one will affect the other.


If we compare the security of the ICANN root to the security of the British
crown jewels, the ICANN root is quite definitely more secure. In the first
place there are rather more controls that can be placed on information than
on a valuable object which must inevitably be in sole custody of a very
limited number of people from time to time. Secondly, the incentive to
default is far greater as the crown jewels would be infinitely easier to
fence.

So given that we are talking about extraordinarily low probabilities in the
first place, the concerns that dominate management of cryptographic keys at
the retail level are almost eliminated when managing a high security root
key.

-- 
Website: http://hallambaker.com/