Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

Florian Weimer <fweimer@bfk.de> Fri, 28 January 2011 08:34 UTC

Return-Path: <fweimer@bfk.de>
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 1C3B23A6950 for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 00:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level:
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 1JBalTrGvYJw for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 00:34:51 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 0B1E93A6933 for <dnsext@ietf.org>; Fri, 28 Jan 2011 00:34:49 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Pijq3-0007sa-Sh; Fri, 28 Jan 2011 08:37:51 +0000
Received: by bfk.de with local id 1Pijq3-0001m3-Oe; Fri, 28 Jan 2011 08:37:51 +0000
To: John Bashinski <jbash@cisco.com>
References: <4D41D3E2.6060107@cisco.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Fri, 28 Jan 2011 08:37:51 +0000
In-Reply-To: <4D41D3E2.6060107@cisco.com> (John Bashinski's message of "Thu\, 27 Jan 2011 15\:21\:54 -0500")
Message-ID: <82r5bxl8yo.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 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 08:34:52 -0000

* John Bashinski:

> I am, however, the person who's writing the internal standards in
> question for the "large router vendor", and I guess I've just authorized
> myself to disclose what the "large router vendor" is thinking about
> doing, so that maybe some of the constraints are a little more clear.

Would it help you if there weren't any vanity key rollovers at all?

Then the remaining cases are, as far as I can see:

  (i) key is lost

  (ii) key is compromised

  (iii) cryptographic algorithms are compromised

  (iv) control of the root zone changes

In cases (i), (iv), you cannot expect that the new key material will
be signed by the old.

In case (ii), you cannot rely on the signature from the old key
material.

In case (iii), you'll likely need a firmware update to implement new
algorithms, and you can ship new key material with that.

What am I missing?

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99