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