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