Re: [dnsext] historal root keys for upgrade path?

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 25 January 2011 20:25 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 49DCC3A6889 for <dnsext@core3.amsl.com>; Tue, 25 Jan 2011 12:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.736
X-Spam-Level:
X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
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 wIcA9l3RT8qv for <dnsext@core3.amsl.com>; Tue, 25 Jan 2011 12:25:57 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CD8233A6869 for <dnsext@ietf.org>; Tue, 25 Jan 2011 12:25:56 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PKSsF1048003 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Tue, 25 Jan 2011 13:28:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D3F3286.8040102@vpnc.org>
Date: Tue, 25 Jan 2011 12:28:54 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <alpine.LFD.1.10.1101251250040.30991@newtla.xelerance.com> <4D3F233C.7000900@vpnc.org> <alpine.LFD.1.10.1101251510140.30991@newtla.xelerance.com>
In-Reply-To: <alpine.LFD.1.10.1101251510140.30991@newtla.xelerance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] historal root keys for upgrade path?
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: Tue, 25 Jan 2011 20:25:58 -0000

On 1/25/11 12:12 PM, Paul Wouters wrote:
> On Tue, 25 Jan 2011, Paul Hoffman wrote:
>
>>> Is something like this even possible? I'm not sure what happens to the
>>> root private keys once they are retired...
>>
>> It is possible, but not in the way you seem to be thinking. If you
>> trusted that hardware/software vendor to securely populate your trust
>> anchor store originally, you can trust them to do so in the future as
>> well.
>
> Well, this is the vendor asking "do we really need to build something
> ourselves"
>
> The anser seems to be "yes". It also means that some devices will fail
> due to
> firewall rules if this updating happens outside of the DNS scope.

I don't understand this. I proposed that the updating procedure use 
fixed IP addresses; are you saying that there are firewalls that prevent 
such communication unless there was a DNS lookup first?

>> Bootstrapping is hard, but once you have done it, you can reuse the
>> trust logic you used to do it again.
>
> Not neccessarilly. Bootstreap happens on a desk at the sysadmin office, not
> neccessarilly on the switch in the production environment....

There is no reason why it can't happen at the switch itself, assuming 
that you have not turned off the "trust the vendor to bootstrap DNSSEC" 
option in the switch's config.