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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 26 January 2011 17:38 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 33F0C3A6917 for <dnsext@core3.amsl.com>; Wed, 26 Jan 2011 09:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level:
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 dlGzsDhp6djZ for <dnsext@core3.amsl.com>; Wed, 26 Jan 2011 09:38:46 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D409B3A6828 for <dnsext@ietf.org>; Wed, 26 Jan 2011 09:38:45 -0800 (PST)
Received: by gxk27 with SMTP id 27so273841gxk.31 for <dnsext@ietf.org>; Wed, 26 Jan 2011 09:41:46 -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=KAWiNOdA39VBwENQbcH1uhePyfIY2UJRtOhFimpC0Cc=; b=enI6JTo9CDSOsPQx6ZWrBMnTwNjo5k1eq/PyH+oXV558W40jmzD0gA/KkVdyuEAc2T r1LgWEEtRZmk0Ij/iNhnygcqY9VjQSGXNoNNW68kZSOmqRppb4Ba8I8wRGQUx0aawxCj tMvS+KJELuUoqRmXvgWfg1dD6EHgk3wLj/BP8=
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=w9hE08w42dBl9nkFogreRhfvgfvDnt6a+0/BpwUBQZ/01/9C3QJCDoTgXlnRwaBhCT 1S8mNbbJZBu6EddVpB451mM7tE8U0cLMkQNWvhNOGJloZpy7MEJaKcU0juYCuJuYE5hl jYtZnHtFyERo+p5/00wf0BWm+jUNk2xf/celM=
MIME-Version: 1.0
Received: by 10.100.134.10 with SMTP id h10mr5158792and.86.1296063706309; Wed, 26 Jan 2011 09:41:46 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Wed, 26 Jan 2011 09:41:45 -0800 (PST)
In-Reply-To: <alpine.LFD.1.10.1101260958490.30991@newtla.xelerance.com>
References: <alpine.LFD.1.10.1101251250040.30991@newtla.xelerance.com> <4D3F233C.7000900@vpnc.org> <alpine.LFD.1.10.1101251510140.30991@newtla.xelerance.com> <alpine.LSU.2.00.1101261442120.3329@hermes-1.csi.cam.ac.uk> <AANLkTinCB-d2HWGY4kSOmfSCMNQ-D61keEE+1poTu11g@mail.gmail.com> <alpine.LFD.1.10.1101260958490.30991@newtla.xelerance.com>
Date: Wed, 26 Jan 2011 12:41:45 -0500
Message-ID: <AANLkTi=KGpm0O8KqGZO6vC+8k64byPFzM4w1Toq+se3E@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Wouters <paul@xelerance.com>
Content-Type: multipart/alternative; boundary="0016e644c708d22361049ac35839"
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: Wed, 26 Jan 2011 17:38:47 -0000

On Wed, Jan 26, 2011 at 10:06 AM, Paul Wouters <paul@xelerance.com> wrote:

> On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:
>
>  If you want to distribute keys for immediate use in the DNS, use the
>> infrastructure designed for that purpose.
>> If you want to perform long term trust root management, use an
>> architecture that is designed for that purpose.
>>
>> X.509v3 is designed to deal with TA keys that are valid for decades. There
>> is experience doing that. There is infrastructure that exists to perform
>> management of such keys in a high security environment. And it is possible
>> to outsource management of such to several providers and is is possible to
>> buy
>> the equipment to do so in-house.
>>
>
> Which CA(s)s would we have to make the products trust? IANA seems to
> be using Godaddy today. Is that guaranteed to last forever? If not,
> then how is a device supposed to know which CA IANA has chosen at some
> time in the future? Do we just have to trust all 1500+ commercial CA? And
> deal with all the revocations? And how to install new ones, using
> what trust? And remember, this is a switch or router, not a browser or
> an OS with the "update now" button.
>


Use a Quorate Root then.

Multiple Signers, are recognized. A valid key must be counter signed by a
quorum of the recognized signers.

This approach is unencumbered as far as I know (Phil Z. described it at
length but did not deploy code).


As Ed Lewis points out, these are really tricky trust problems and there are
good reasons not to want to trust any monolithic single rooted scheme.

There are much larger International IT efforts than DNSSEC that have
collapsed due to failure to agree on this type of issue.

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