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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 28 January 2011 17:29 UTC

Return-Path: <Ted.Lemon@nominum.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 9A96E3A6918 for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.439
X-Spam-Level:
X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 HeYPWZeu6N2u for <dnsext@core3.amsl.com>; Fri, 28 Jan 2011 09:29:15 -0800 (PST)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id CE23F3A67C2 for <dnsext@ietf.org>; Fri, 28 Jan 2011 09:29:14 -0800 (PST)
Received: from source ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTUL9pcDq1hxmPSiGosPJL5siKp9uIMt/@postini.com; Fri, 28 Jan 2011 09:32:21 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4E9591B82ED for <dnsext@ietf.org>; Fri, 28 Jan 2011 09:32:21 -0800 (PST)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3D02119005D; Fri, 28 Jan 2011 09:32:21 -0800 (PST)
Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 09:32:20 -0800
MIME-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <562C7583-B719-482F-B201-EFB54138BAF1@icsi.berkeley.edu>
Date: Fri, 28 Jan 2011 12:32:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <E4865E48-383B-4591-AF27-34571C4AA367@nominum.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>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
X-Mailer: Apple Mail (2.1082)
Cc: george.barwood@plueyonder.co.uk, dnsext List <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 17:29:17 -0000

On Jan 28, 2011, at 12:12 PM, Nicholas Weaver wrote:
> As long as all the historical data is available someplace that the device knows about (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 .  Or pick whatever...), there is no excuse for not using this style of mechanism.

There's no way to validate this, so you might was well be trusting instructions written on a bathroom wall.

It's important to recognize two aspects of a key here: the value of the key, and the security of the key.   The root zone key is extraordinarily valuable; if you have it, you can do all kinds of fun bad things with it.   So the incentive to compromise this key is very high.

A corporate key for signing firmware is less valuable.   Of course, if it's used to sign firmware in millions of devices, it's not a *lot* less valuable, but it is less valuable.   The fewer devices it was used in, the less valuable it is.

This suggests another knob to tweak.  Firmware in self-updating devices should have a manufacturer-configured key, but the manufacturer should use that key in no more than N devices, for some TBD value of N.   This reduces the value of the firmware key, more substantially the smaller N is, to a limit of N=1.

> Anything else MUST either add additional keys to the trusted root, and/or becomes the trusted root instead.  In the former you're weakening the system (you now trust both the . KSK AND some 'random' PKI certificate, as a compromise of EITHER is sufficient to break your security), in the latter you're just replacing one key roll problem with a second (how do you roll the PKI certificate?).

I think it's important to realize that any device that auto-updates already has one of these keys in it, and that key can be used to update the root zone key on the device, if the device even has a root zone key on it.   So it's not the case that this mechanism makes things less secure.

It's certainly possible to contemplate some regime in which the device key *couldn't* be used to update the root zone key, but I am skeptical that this would be practiced.   So in practice, this problem exists, and is not going away, so it would be better to describe a set of best practices for vendors who use this technique, rather than pretending the technique isn't being used.

We can certainly have a debate about which sort of compromise is more or less likely, but I find the idea of a "limited leap of faith" sort of like the idea of a "limited leap off a cliff."   Unless the cliff is only a few feet high, the absolute height of the cliff is immaterial.