Re: [dnsext] A question about the need for "historical keys"
John Bashinski <jbash@cisco.com> Fri, 28 January 2011 18:23 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 CE56E3A6932 for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 10:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 7h6kAO1aiIhp for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 10:23:27 -0800 (PST)
Received: from vps1.velvet.com (vps1.velvet.com [66.249.7.50]) by core3.amsl.com (Postfix) with ESMTP id D06C13A67D1 for <dnsext@ietf.org>; Fri, 28 Jan 2011 10:23:26 -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 2435B1A530B; Fri, 28 Jan 2011 13:26:31 -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 519EC3061; Fri, 28 Jan 2011 13:26:30 -0500 (EST)
Message-ID: <4D430A56.9040600@cisco.com>
Date: Fri, 28 Jan 2011 13:26:30 -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: Edward Lewis <Ed.Lewis@neustar.biz>
References: <4D41D3E2.6060107@cisco.com> <3125F45F-7594-498F-AFA3-D2D738A228F5@hopcount.ca> <4D42ED13.5030000@cisco.com> <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu> <E4865E48-383B-4591-AF27-34571C4AA367@nominum.com> <4D430265.8020100@cisco.com> <a06240802c968b4fefc24@[10.31.200.110]>
In-Reply-To: <a06240802c968b4fefc24@[10.31.200.110]>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigB0C72AC147F87B55B9E71D00"
Cc: dnsext@ietf.org
Subject: Re: [dnsext] A question about the need for "historical keys"
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 18:23:27 -0000
On 2011-01-28 13:08, Edward Lewis wrote: > Why is the updating of the DNSSEC root-zone KSK different than > updating any other piece of data, configuration, or code (soft or > firmware) in a dormant piece of equipment? Well, first of all, DNS is absolutely pervasive. Everything uses it. Second, you may need DNS as part of the network infrastructure to let you get the other updates. Third, DNS keys get updated on a schedule not under the vendor's control, by an entity not under the vendor's control, and we're only guaranteed 60 days' notice. And the users' trust for those data is fundamentally in that entity, not in the vendor, so it's *appropriate* that that entity get control over the keys. Fourth, for much of the equipment we're dealing with, this may be the *only* piece of information that ever gets updated during the entire lifetime of the product. Take the Linksys home routers. My guess is that maybe a couple of percent of them *ever* get firmware updates. Most users don't even change the factory default configuation. They plug the router in, plug some computers into the other side, and forget about it. At most they set up WiFi encryption, and that only reluctantly, because we force it on them. And that's an entirely local process in which they have to trust nothing. They definitely don't have to evaluate the trustworthiness of some random string of hex digits downloaded from some alphabet soup entity they've never heard of, in order to protect from a threat they don't understand. People install these things and forget them unless they break. The standard operational model simply does not include software updates. > I ask this to see if there is some requirement that leads to a crafted > solution for this problem. I just don't see that this is a special > case, we have other ways to update stuff already. Every device has its own specific way or ways to update its own specific set of data. So we can either fix DNS once, or we can rework every one of those thousands of update paths to support DNS. -- 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