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

Andrew Sullivan <ajs@shinkuro.com> Fri, 04 March 2011 12:12 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 4445B3A6996 for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 04:12:12 -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 fiuVYQg0HqhL for <keyassure@core3.amsl.com>; Fri, 4 Mar 2011 04:12:11 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7AE733A68A7 for <keyassure@ietf.org>; Fri, 4 Mar 2011 04:12:11 -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 187A91ECB41D for <keyassure@ietf.org>; Fri, 4 Mar 2011 12:13:20 +0000 (UTC)
Date: Fri, 04 Mar 2011 07:13:18 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: keyassure@ietf.org
Message-ID: <20110304121318.GG16012@shinkuro.com>
References: <6B5E58CC-4DBB-4C43-93F4-FC97A9D358AA@checkpoint.com> <E1PvSbG-0003G9-Nd@login01.fos.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1PvSbG-0003G9-Nd@login01.fos.auckland.ac.nz>
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 12:12:12 -0000

On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote:
> is finalised all I need to do is plug the algorithm in.  Putting the same
> thing into DANE isn't hard, and makes it easier to deploy future-compatible
> implementations from day one.

I don't see any reason to say specifically, "We'll be moving to _x_ so
you better have a placeholder for it".  That will simply encourage
foolish programmers to write one placeholder spot, and then when SHA-4
or whatever comes along we have a new problem.

The right way to do this is something like the unknown RRTYPE in DNS.
In that case, you have to be able to handle anything you get (within
the valid codepoint range) _even if_ you don't understand it.  By
"handle", I mean, "be able to pass messages; not spit up and die," and
so on.  It does not mean, of course, that you have to be able to do
whatever additional section processing or whatever is required, and
you don't need to be able to do anything useful (if you don't know
what NSEC3 is, you're not going to be able to validate with it).  

I'm not sure how to say something similar in this case, but I think
it's the right sort of framework.

A

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