[dnsext] Moderate one's tone, please. (was: draft-jabley-dnsop-validator-bootstrap-00)

Andrew Sullivan <ajs@shinkuro.com> Tue, 01 February 2011 14:40 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E981C3A6D4B for <dnsext@core3.amsl.com>; Tue, 1 Feb 2011 06:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.792
X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id eafS7+GggBUf for <dnsext@core3.amsl.com>; Tue, 1 Feb 2011 06:40:17 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info []) by core3.amsl.com (Postfix) with ESMTP id 16F6A3A6CEA for <dnsext@ietf.org>; Tue, 1 Feb 2011 06:40:17 -0800 (PST)
Received: from crankycanuck.ca (external.shinkuro.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F3D461ECB422 for <dnsext@ietf.org>; Tue, 1 Feb 2011 14:43:33 +0000 (UTC)
Date: Tue, 1 Feb 2011 09:43:32 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: dnsext@ietf.org
Message-ID: <20110201144332.GD3135@shinkuro.com>
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> <4D476699.5060105@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4D476699.5060105@vpnc.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: [dnsext] Moderate one's tone, please. (was: 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 14:40:18 -0000

Not to pick on Paul, but again, I'd like to suggest a moderation of
tone.  I understand perfectly well that there are strong views here,
and I also think there is a perfectly legitimate technical dispute
here.  But let's go out of our collective way to keep our responses as
even as possible precisely so that we can get to a satisfying
conclusion for everyone.



On Mon, Jan 31, 2011 at 05:49:13PM -0800, Paul Hoffman wrote:
> 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!
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext

Andrew Sullivan
Shinkuro, Inc.