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

Phillip Hallam-Baker <hallam@gmail.com> Fri, 28 January 2011 05:31 UTC

Return-Path: <hallam@gmail.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 B67783A6BA2 for <dnsext@core3.amsl.com>; Thu, 27 Jan 2011 21:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.474
X-Spam-Level:
X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 3DIdnsFEbgIx for <dnsext@core3.amsl.com>; Thu, 27 Jan 2011 21:31:17 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5CAF23A6B9C for <dnsext@ietf.org>; Thu, 27 Jan 2011 21:31:17 -0800 (PST)
Received: by ywk9 with SMTP id 9so1051706ywk.31 for <dnsext@ietf.org>; Thu, 27 Jan 2011 21:34:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+UaZhYRXT9/EJocA9AGoewB66ne/mQdkfN+YN+DgNew=; b=xMLI1BguNf9Bc59tYmwS4csn3ikDQu0HDKRhR4OJUVsYsNu/pMHcHOEqTKjaFmgMiJ 1xoxzpP9g2xK8O/76MO97uhiwJKvqjhrXmEwlj4NktylPLHoxb/aBpETgUTztgtc7JCP /BLMPdI6LTsUZx/zA7kP79clfkCJOA8Luh9HE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mgzsFUM/a8Ton7T6HyWLADiOm5YisHBFkXpAfmEblDcnojZ/uWvL7pLChrSIH0Ko4s vUvQA8ALnJnbr2sMUTbqRFCOesQbcJK39JEXtAkJ78VuG/4OO2jzYl3tZ7FGBdx8KocD K7k6Z4yEF47EtWUK8NAfQoE5688sOe+iyuqEg=
MIME-Version: 1.0
Received: by 10.100.195.12 with SMTP id s12mr1283256anf.18.1296192860846; Thu, 27 Jan 2011 21:34:20 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Thu, 27 Jan 2011 21:34:20 -0800 (PST)
In-Reply-To: <4D41D3E2.6060107@cisco.com>
References: <4D41D3E2.6060107@cisco.com>
Date: Fri, 28 Jan 2011 00:34:20 -0500
Message-ID: <AANLkTin0i3b8bC6+5NmmAQkrLruN6jhsy1mYciiReos2@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: John Bashinski <jbash@cisco.com>
Content-Type: multipart/alternative; boundary="0016e644c63007fb9f049ae16ba5"
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 05:31:18 -0000

On Thu, Jan 27, 2011 at 3:21 PM, John Bashinski <jbash@cisco.com> wrote:

>
> Using the current public X.509 PKI is NOT under consideration.
>
> Just to be clear, it was never proposed, except as a straw man by Paul
Wouters.

What I suggested was that we look at the possibilities of using X.509
standards and infrastructure that has been developed to meet similar
considerations in that space. I think it is abundantly clear that we do not
want the criteria for signing the root KSK to be  inclusion in some browser
root anchor list.

X.509 is designed to deal with persistent keys, DNS is not designed to
persist data.


I think that we should detach this problem from DNSSEC because we are going
to face the same problem for device keys. We have over the years created
quite a few consortiums that sign various CA certs for device keys and we
are in the process of creating more.

Ultimately these devices are going to have to tie into enterprise networks
and recognize the root of trust for the enterprise regardless of whether
their function requires them to also process DNSSEC or not.

So I would look to develop a scheme that addresses the problem of managing
the enterprise trust root first and then consider the IANA root key as being
a special case that would reuse the same code and management principles.


-- 
Website: http://hallambaker.com/