Re: [keyassure] Opening issue #21: "Need to specify which crypto

Andrew Sullivan <ajs@shinkuro.com> Fri, 04 March 2011 14:50 UTC

Return-Path: <ajs@shinkuro.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C953A687E for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 06:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level:
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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-jJLlv6205v for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 06:50:22 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 828293A6864 for <keyassure@ietf.org>; Fri, 4 Mar 2011 06:50:22 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6CD741ECB41D for <keyassure@ietf.org>; Fri, 4 Mar 2011 14:51:31 +0000 (UTC)
Date: Fri, 04 Mar 2011 09:51:29 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: keyassure@ietf.org
Message-ID: <20110304145129.GF16703@shinkuro.com>
References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> <E1PvSbG-0003G9-Nd@login01.fos.auckland.ac.nz> <20110304121318.GG16012@shinkuro.com> <4D70F8FA.7020506@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4D70F8FA.7020506@vpnc.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 14:50:23 -0000

On Fri, Mar 04, 2011 at 06:36:42AM -0800, Paul Hoffman wrote:
> The way I read Warren's proposal, we get exactly what you want. There  
> are two different mandatory code points defined for two different  
> hashes, so we are sure that the deployed code will be able to handle  
> hash agility. We don't care which algorithm people use in practice  
> because they are both mandatory, so there is no spitting up or dying.
>
> Does that work for you?

Sort of.  Maybe it's recent exposure to brain-dead programmers, but
I've encountered the situation where a spec says, "There are now two;
there might be more in the future."  What the programmer does is go
away and write an implementation that has the two, and puts a comment
in the code that says, "Future code changes may need to be here,
because there might be new things defined."  Or something like that.

As I say, I can't think of much to say about this that's different, so
maybe I'm fretting over nothing.  But algorithm maintenance is already
a headache for DNSSEC, and we've only started deployment.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.