Re: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please!

Steve Crocker <steve@shinkuro.com> Thu, 03 September 2009 12:33 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801C13A684C; Thu, 3 Sep 2009 05:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.834
X-Spam-Level:
X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DSL=1.129, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3]
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 Vac8garLIb+t; Thu, 3 Sep 2009 05:33:49 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FE333A6832; Thu, 3 Sep 2009 05:33:49 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1MjBNx-000NVc-GG for namedroppers-data0@psg.com; Thu, 03 Sep 2009 12:25:53 +0000
Received: from [216.194.124.237] (helo=execdsl.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <steve@shinkuro.com>) id 1Mj5IW-000H34-K8 for namedroppers@ops.ietf.org; Thu, 03 Sep 2009 05:55:52 +0000
Received: from [71.142.160.125] (HELO [10.214.7.26]) by execdsl.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 17998218; Wed, 02 Sep 2009 23:55:37 -0600
Cc: Steve Crocker <steve@shinkuro.com>, Andrew Sullivan <ajs@shinkuro.com>, DNSEXT WG <namedroppers@ops.ietf.org>, "Scott W. Rose" <scott.rose@nist.gov>
Message-Id: <37456F94-B77B-4842-9583-8E56C8B74F83@shinkuro.com>
From: Steve Crocker <steve@shinkuro.com>
To: Patrik Fältström <paf@cisco.com>
In-Reply-To: <577B1F45-F1C0-4024-9B9E-F4849790084F@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please!
Date: Thu, 03 Sep 2009 01:55:48 -0400
References: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.com> <434ECD68-79BB-45F1-8A68-A4CD8E4A3E11@cisco.com> <20090902161155.GS16078@shinkuro.com> <577B1F45-F1C0-4024-9B9E-F4849790084F@cisco.com>
X-Mailer: Apple Mail (2.936)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

Patrik,

Thanks for taking on this task.  I am a bit confused about what you're  
reporting.  I understand there is controversy about whether the WG  
should be more or less permissive in the admission of new algorithms,  
but our proposal is neutral with respect to that issue.  We propose to  
include signalling in the query in order to facilitate the phase out  
of old algorithms when newer ones are being fielded.

It some are arguing that the very existence of the signalling  
mechanism may open the door to too many algorithms, I want to push  
back vigorously.  We did not create this proposal in order to  
facilitate the adoption of more algorithms.  At least some new  
algorithms are clearly coming, e.g. SHA256 and ECC, so there's no  
question that we will face one or more transitions.  If there is to be  
a linkage between our proposal and Paul Hoffman's, it should be in the  
other direction.  Our proposal should be adopted in all cases.  His  
proposal should not be adopted unless ours is too.

The only detail that might be affected by future policy is how many  
algorithm identifiers to anticipate.  I believe we can signal which of  
256 different algorithms are known to the requester.  If this is  
insufficient, then the field that encodes that subset needs to be  
adjusted.  But I sincerely hope we're not going to come anywhere close  
to that number in the foreseeable future.

So, can you clarify if you really did get input that tended to push  
against our proposal because it might be seen as permissive toward  
admitting new algorithms?

Thanks,

Steve



On Sep 2, 2009, at 6:20 PM, Patrik Fältström wrote:

> On 2 sep 2009, at 18.11, Andrew Sullivan wrote:
>
>> On Thu, Aug 27, 2009 at 06:18:29AM +0200, Patrik Fältström wrote:
>>>
>>> - what the impact *really* is on DNSSEC deployment if we have  
>>> multiple
>>> algorithms
>>> - how an algorithm change is to handled
>>> - how to handle the selection process of preferred (plural)  
>>> algorithms
>>> (one main, and one secondary that is rolled in or out?)
>>>
>>> Given this, we can talk about how to do the wording in documents  
>>> that
>>> talk about how to register/signal algorithms.
>>
>> If I read this correctly, then either the candidate draft that Paul
>> Hoffman has offered to the WG, possibly with some additions or
>> changes, or something with the same topic is a necessary condition  
>> for
>> adopting draft-crocker-dnssec-algo-signal; and if such a document is
>> adopted and published, then draft-crocker-dnssec-algo-signal would
>> also be a good idea.  Am I reading correctly?
>
> Yes, that was my reading of what people told me (~10 people) after  
> the Stockholm meeting. People where nervous that, although it is  
> very good to have registration and signalling of algorithms, having  
> those mechanisms would increase the number of algorithms to a point  
> which it has impact on interoperability (and therefore usability) of  
> DNSSEC.
>
> If I am wrong in my findings, or if 10 people actively looking me up  
> is a too small group to impact the work of this wg (I was suprised  
> over such *high* number), let the chairs know.
>
>   Patrik
>