Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 01 February 2011 01:45 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 D74003A6CB3 for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 17:45:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.137
X-Spam-Level:
X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, SARE_LWSHORTT=1.24, 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 z-ZyhAEUtk7P for <dnsext@core3.amsl.com>; Mon, 31 Jan 2011 17:45:59 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 0A19C3A6CAD for <dnsext@ietf.org>; Mon, 31 Jan 2011 17:45:58 -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 p111nD63090730 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <dnsext@ietf.org>; Mon, 31 Jan 2011 18:49:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D476699.5060105@vpnc.org>
Date: Mon, 31 Jan 2011 17:49:13 -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: <3E0BC533-AFF7-4E5E-A52E-BD7814FC4060@hopcount.ca> <4D472D2C.9090108@cisco.com> <6819D144-A148-41AB-BF38-A888E0950D7E@hopcount.ca> <AANLkTikx-cc47UFjK6=DxwxJVraMv89L-ebBmhHPn7ZE@mail.gmail.com>
In-Reply-To: <AANLkTikx-cc47UFjK6=DxwxJVraMv89L-ebBmhHPn7ZE@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00
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, 01 Feb 2011 01:45:59 -0000

On 1/31/11 4:40 PM, Phillip Hallam-Baker wrote:
> To be precise here, there is no difference in the likelihood that the
> keys will be compromised.

Quite right.

> The difference is that the X.509 protocol is designed to support keys
> that are persistent over long periods (decades) and DNSSEC is not.

Poppycock. Both PKIX and DNSSEC are agnostic on how long the keys are 
meant to last. Pretending that PKIX has some advantage here is nonsense.

> In particular an X.509 self-signed certificate is an assertion that the
> key holder will maintain and use the associated private key in
> accordance with the specified practices for the specified length of time.

Bosh. If you are talking about the "notAfter" field, it is defined as 
the end of "the time interval during which the CA warrants that it will 
maintain information about the status of the certificate"; that is quite 
different than "maintain and use". If you are speaking of something 
else, please quote from the PKIX spec.

> You can easily find out how long Comodo or Symantec or whoever is going
> to maintain their SSL CA roots, the information is right there in the
> cert store and is irrevocable in that the CA can extend the time period
> (through recertification) but cannot reduce it.

Balderdash. When I look in Comodo's certificate in my "cert store", I 
don't see anything about how long you are going to maintain your SSL CA 
root. I see something that says you will maintain *information about the 
status* of the certificate; note the difference. As for "irrevocable", 
that's just silly: Comodo can revoke it at any time. There is no 
contract here.

> My advice to Cisco would be to use their existing root to sign the
> published CSR for the DNS root KSK in the short term at least.

Signing is the easy part: making their systems use that signed key is 
much more difficult. That difficulty is what started this thread; 
handwaving it away won't help Cisco or anyone.

> In the longer term we are going to have to have a look at the problem at
> a higher level and work out how we are going to solve it in a scalable
> way across all the platforms that involve a root key.
>
> We are starting to make quite a little collection of industry forums
> that are doing this root key management as a sideline.

Now everyone can rest assured: industry forums to the rescue!