Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
John Bashinski <jbash@cisco.com> Fri, 28 January 2011 22:12 UTC
Return-Path: <jbash@cisco.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 007013A68BD for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 14:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 COCdHPejOGmV for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 14:12:09 -0800 (PST)
Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id 08B023A689E for <dnsext@ietf.org>; Fri, 28 Jan 2011 14:12:09 -0800 (PST)
Received: from candyfloss.jbash.velvet.com (206-248-144-221.dsl.teksavvy.com [206.248.144.221]) by vps1.velvet.com (Postfix) with ESMTPSA id AF9541A5319; Fri, 28 Jan 2011 17:15:12 -0500 (EST)
Received: from candyfloss.jbash.velvet.com (candyfloss.jbash.velvet.com [127.0.0.1]) by candyfloss.jbash.velvet.com (Postfix) with ESMTP id A86C53061; Fri, 28 Jan 2011 17:15:11 -0500 (EST)
Message-ID: <4D433FEF.9060406@cisco.com>
Date: Fri, 28 Jan 2011 17:15:11 -0500
From: John Bashinski <jbash@cisco.com>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7
MIME-Version: 1.0
To: Thierry Moreau <thierry.moreau@connotech.com>
References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42F597.8090006@vpnc.org> <4D42FCB6.70005@cisco.com> <4D43072D.6090503@vpnc.org> <4D431F94.4020701@cisco.com> <4D433B9D.7030209@connotech.com>
In-Reply-To: <4D433B9D.7030209@connotech.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigAFFEE6D10ED492269F3CE62D"
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, dnsext@ietf.org
Subject: Re: [dnsext] Historical root keys: The Large Router Vendor Speaks
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 22:12:10 -0000
On 2011-01-28 16:56, Thierry Moreau wrote: > But once IANA (or whichever organization makes it "public") commits to > "it" on a long term it becomes by definition more trustworthy than the > root KSK. How does that work? All validations are funneled through through the root KSK. Furthermore, once you're bootstrapped, all your trust anchor updates come as RFC 5011 signed by the root KSK. So there's no way to have anything more trusted than the root KSK. This is in the technical sense of "trusted", which is more or less equivalent to "able to spoil your day". The originally proposed form of "it" was for "it" to *be* the root KSK. You'd start with a root KSK, and if that KSK were still in use, you'd be done. If not, you'd get "it" in the form of a history of root KSK rollovers, run through the chain, and thereafter anchor yourself at the current root KSK. I still prefer that approach, but other people seem to prefer alternatives. Not even those the alternatives create anything that I can see as "more trusted" than the root. "Equally trusted" at most. > Then suddenly the trust foundation shifts from the root KSK > to "it" and soon it becomes best practice to use it as the normal way > to bootstrap DNSSEC resolution. Well, it certainly wouldn't be the only available way, but, yes, it probably would be the most common way. What do you believe should be the "normal way"? > Ah ah! Now "it" becomes the (default) new trust foundation. I knew it > would come sooner than later. In order to enable DNSSEC by default, it MUST be possible to bootstrap it without human intervention, using only the information available to you when you first get turned on. That's what "default" means. The current default is not to use DNSSEC at all. A tiny minority enables DNSSEC. That tiny minority would still be able to do whatever it wanted to set up trust anchors... including what it's doing today. So what's the alternative? -- jbash
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- [dnsext] Historical root keys: The Large Router V… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Joe Abley
- Re: [dnsext] Historical root keys: The Large Rout… David Conrad
- Re: [dnsext] Historical root keys: The Large Rout… Brian Dickson
- Re: [dnsext] Historical root keys: The Large Rout… Jakob Schlyter
- Re: [dnsext] Historical root keys: The Large Rout… Florian Weimer
- Re: [dnsext] Historical root keys: The Large Rout… George Barwood
- Re: [dnsext] Historical root keys: The Large Rout… Alex Bligh
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Andrew Sullivan
- Re: [dnsext] Historical root keys: The Large Rout… Joe Abley
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Paul Hoffman
- Re: [dnsext] Historical root keys: The Large Rout… Nicholas Weaver
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… Alex Bligh
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- [dnsext] A question about the need for "historica… Edward Lewis
- Re: [dnsext] Historical root keys: The Large Rout… Paul Hoffman
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] A question about the need for "histo… John Bashinski
- Re: [dnsext] A question about the need for "histo… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] A question about the need for "histo… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Ted Lemon
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Thierry Moreau
- Re: [dnsext] Historical root keys: The Large Rout… John Bashinski
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Thierry Moreau
- Re: [dnsext] Historical root keys: The Large Rout… Paul Wouters
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Tony Finch
- Re: [dnsext] Historical root keys: The Large Rout… Chris Thompson
- Re: [dnsext] Historical root keys: The Large Rout… George Barwood
- Re: [dnsext] Historical root keys: The Large Rout… Tony Finch
- Re: [dnsext] Historical root keys: The Large Rout… Phillip Hallam-Baker
- Re: [dnsext] Historical root keys: The Large Rout… Olafur Gudmundsson