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

Paul Wouters <paul@xelerance.com> Wed, 26 January 2011 18:02 UTC

Return-Path: <paul@xelerance.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 1BDCE3A6850 for <dnsext@core3.amsl.com>; Wed, 26 Jan 2011 10:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.573
X-Spam-Level:
X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599]
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 CDxeRGJzr9jb for <dnsext@core3.amsl.com>; Wed, 26 Jan 2011 10:02:19 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id D58773A6818 for <dnsext@ietf.org>; Wed, 26 Jan 2011 10:02:18 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 47B89BF8B; Wed, 26 Jan 2011 13:05:18 -0500 (EST)
Date: Wed, 26 Jan 2011 13:05:17 -0500
From: Paul Wouters <paul@xelerance.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
In-Reply-To: <AANLkTi=KGpm0O8KqGZO6vC+8k64byPFzM4w1Toq+se3E@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.1101261256250.17193@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> <AANLkTi=KGpm0O8KqGZO6vC+8k64byPFzM4w1Toq+se3E@mail.gmail.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 18:02:20 -0000

On Wed, 26 Jan 2011, Phillip Hallam-Baker wrote:

> 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.

Maybe we can add even more complexity to this?

The path here is extremely clear. It hopes from a common trusted key to new keys via intermediate steps,
all of which are signed. To bring in any other outside trusted third party with its own pletora of
trust anchor update issues is not solving the problem. You are just moving the problem. Worse, you are
moving the problem away from the original trusted parties into a hypothetical bag of other trusted parties
with even less clear mandates.

> 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. 

Please either specifically mention the reasons, or stop waiving your generalities. DNSSEC is already
trusting "monolithic single rooted scheme", so suggesting we destroy that is moot. There is no valid
reason to bring in third parties. Let alone insist that validating resolvers need to gain ASN.1 parsers
and X.509 trust anchors. Seriously, grab a 10 year old browser and tell me how well this "proven technology"
works? How many of those CA's are still valid today? How could we have guaranteed to have picked one that
is still active today - provided there is any?

We already have a fully functional path of trust, from root key to root key, that is validatable by DNSSEC.

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

Yeah, the Government of Canada's Entrust X.509 scheme comes to mind.......

Paul