Re: [dnsext] A question about the need for "historical keys"

Paul Wouters <paul@xelerance.com> Fri, 28 January 2011 19:09 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 6F6333A680E for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 11:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 agpHaKHNorzm for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 11:09:10 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 648283A67F7 for <dnsext@ietf.org>; Fri, 28 Jan 2011 11:09:10 -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 8967FC542; Fri, 28 Jan 2011 14:12:15 -0500 (EST)
Date: Fri, 28 Jan 2011 14:12:15 -0500
From: Paul Wouters <paul@xelerance.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CB2E6797-C219-4675-A14E-8F7F3FF7A2D5@nominum.com>
Message-ID: <alpine.LFD.1.10.1101281402540.29398@newtla.xelerance.com>
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]> <4D430A56.9040600@cisco.com> <CB2E6797-C219-4675-A14E-8F7F3FF7A2D5@nominum.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: Edward Lewis <Ed.Lewis@neustar.biz>, 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 19:09:11 -0000

On Fri, 28 Jan 2011, Ted Lemon wrote:

> On Jan 28, 2011, at 1:26 PM, John Bashinski wrote:
>> Take the Linksys home routers. My guess is that maybe a couple of
>> percent of them *ever* get firmware updates.
>
> Before you use this as a basis for argument, it might be worth your while to (not in this discussion) explore the question of *why* they don't get updates.   From my own personal experience, this is not because of a lack of demand.

You can ask the firefox people. They have seen a massive increase in updates just
by sneakilly downloading the update in the background and telling the user "the update
is ready to be installed, proceed?". The users who tend not to be able to manually
update a product is exactly the class of users that will say "if it aint broken, don't
fix it".

I think the case of the consumer router is a good one. We all have a box of these old
routers. If our router, or a friends router breaks, we pull out a device and give it to
them. Where we might update it before giving it, non-geeks will just hand it over. It
worked two years ago, why would it not work now?

The receiver will likely factory default it (because they and/or you forgot the password).

Likely, at that moment they won't have an internet connection, because that's why they
needed the router. It has just to work without updates. If this device now has an old root
key and no automated way of updating it, your friend will not have a working internet
connection, and the device is considered "broken".

And there are many more scenarios. A more enterprise aimed product might require that
you know the vendor login/password before you can download the upgrade.

Paul