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

Joe Abley <jabley@hopcount.ca> Fri, 28 January 2011 14:35 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 7EA473A685B for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 06:35:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level:
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Fam3xiE3LnXF for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 06:35:01 -0800 (PST)
Received: from monster.hopcount.ca (monster.hopcount.ca [216.235.14.38]) by core3.amsl.com (Postfix) with ESMTP id 3FFAC3A6826 for <dnsext@ietf.org>; Fri, 28 Jan 2011 06:35:01 -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 1PipWl-000FuA-9b; Fri, 28 Jan 2011 14:42:23 +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: <3A1DEE95-8C8E-4C89-97EB-6D8F799ADE25@virtualized.org>
Date: Fri, 28 Jan 2011 09:37:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C4E4A03-A589-4B45-BA68-F0E43296E2B0@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>
To: David Conrad <drc@virtualized.org>
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 List <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: Fri, 28 Jan 2011 14:35:02 -0000

On 2011-01-28, at 01:06, David Conrad wrote:

> On Jan 26, 2011, at 1:26 PM, Joe Abley wrote:
>> Wouter's earlier proposal which is mentioned elsewhere in this thread had the principle defect that its use relied upon trusting signatures made by old keys, which in general some of us thought was a poor idea (e.g. in the event that a key was rolled because it was compromised).
> 
> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presumably, when a key is known to be compromised, the chain from old to current keys would be broken such that automated systems would require human intervention.

That's not what the trust-history proposal was about; in that proposal every outgoing key would be used to sign a copy of its subsequent incoming key, such that any validator coming on-line from a long time in the dark would have a path to the current key, no matter what key it was using before.

Downloading the trust anchor from the XML file and finding a way to trust it does not involve signatures made by previously-used KSKs, however.


Joe