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

Phillip Hallam-Baker <hallam@gmail.com> Mon, 31 January 2011 13:11 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 7755F3A6C13 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level:
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, 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 pFPlGIrs5QEK for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 05:11:31 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id CB96E3A6C06 for <dnsext@ietf.org>; Mon, 31 Jan 2011 05:11:30 -0800 (PST)
Received: by ywk9 with SMTP id 9so2263966ywk.31 for <dnsext@ietf.org>; Mon, 31 Jan 2011 05:14:45 -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=nQrXbaQnbx6yrpBzkrwbW4aeOH4FyWgvigeU/fUVm50=; b=uENCCR5NInO/xFXJU6cGjTcYbNVJbKF/dw7hq8jclAxr3fR3DYLVk31q3wshiljuJJ o4ABEy6lDOwk9KtoZlzTmirSIQrs7/UTv/Dk57sUt873Xc/AA7+sbrgFe+CBbKasPtkn cE92lmEyZCtN36VkYjvzKykFALtU6J8cBelWg=
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=eX+sAB/dF0U0qT5dv3rf5b8WdQyLixObkywQHex5yODs+rypHlspTlK3t+kuAvQWNi jy/LlCjKXvMgT7yAreztzsbVHdfFC3QUhp7V0JOS+qJb2fE+z5VWSxB2RSKXmMGl+JZE 6ajx5P1ZK+YiRQlYjHjmmmf4uZJx8gEZPdLLs=
MIME-Version: 1.0
Received: by 10.100.8.9 with SMTP id 9mr3910289anh.120.1296479684856; Mon, 31 Jan 2011 05:14:44 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Mon, 31 Jan 2011 05:14:44 -0800 (PST)
In-Reply-To: <AANLkTinbjRebooyqWMpZ2oTudruoDSGqgaXXr35WPYVH@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>
Date: Mon, 31 Jan 2011 08:14:44 -0500
Message-ID: <AANLkTikiqe2K4S-dNsyQZ-xp71J4bM11SsahwpxfDKCX@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6441dd8130b86049b2433cb"
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsext@ietf.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:11:32 -0000

On Mon, Jan 31, 2011 at 12:21 AM, Brian Dickson <
brian.peter.dickson@gmail.com> wrote:

>
> HOWEVER, and this is important, requiring TWO trust anchors of equal
> strength (same algorithm, same number of bits) to BOTH chain-validate
> the current root key properly as part of the bootstrap, where one of
> those is a previous root key, has some distinct advantages:
> - two keys (at least) would need to be compromised to compromise the target
> - the possible compromise of a root key, followed by rolling the key,
> means that the risk from following 5011 with that key, is only a
> problem if the other bootstrap key is also compromised
> - the value of compromising just the other bootstrap key is nearly
> zero, since that is necessary but not sufficient to compromise the
> target - thus limiting the value of this effort dramatically
> ----> having one trust anchor only (which is not based on the root
> key) does NOT have this benefit
> - minimizing the window of opportunity for attack (a one-time-only
> affair) further limits the value, and consequently lowers the
> likelihood of even an attempt being made
>

I think it would be a good idea to have a separate chain of trust in this
instance.

ICANN has reserved the right to roll the root and according to one post
requires the ability to do so at 60 days notice. To me that says that ICANN
does not want to be the ultimate root of trust for everything on the
Internet. They would be very ill advised to change that decision.

The main challenge in setting up an alternative chain would be to find a
party willing to run it that everyone involved can trust. Which is probably
impossible.


My view is that any ultimate root of trust would have to have a multiple
signer configuration and would have to be available for more than just one
technology. The cost of doing such a root right would be considerable. Using
it for DNS alone would be a waste.

Besides DNS there are many other critical roots that are at issue. Device
authentication for example, there is a similar issue with RFID.

Running such schemes becomes complicated because they end up hitting
government security concerns. If every electronic device requires an
identifier issued by a single entity under the control of one government,
other governments wonder if that might be used as a weapon in a trade
dispute.

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