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

Patrik Fältström <paf@cisco.com> Thu, 27 August 2009 04:23 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 58F273A68B1; Wed, 26 Aug 2009 21:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 agq3qlpD9J33; Wed, 26 Aug 2009 21:23:40 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 27FDA28C12C; Wed, 26 Aug 2009 21:23:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1MgWSS-000MHv-2y for namedroppers-data0@psg.com; Thu, 27 Aug 2009 04:19:32 +0000
Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from <pfaltstr@cisco.com>) id 1MgWSO-000MGv-1d for namedroppers@ops.ietf.org; Thu, 27 Aug 2009 04:19:30 +0000
X-Files: PGP.sig : 186
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAE+mlUpAZnme/2dsb2JhbAC/eYg5kBQFhBo
X-IronPort-AV: E=Sophos; i="4.44,283,1249257600"; d="sig'?scan'208"; a="55661035"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2009 04:19:26 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7R4JQ2r020305; Thu, 27 Aug 2009 00:19:26 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7R4JQA5019986; Thu, 27 Aug 2009 04:19:26 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 00:18:32 -0400
Received: from [192.168.1.4] ([10.82.239.7]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 00:18:31 -0400
Cc: "namedroppers@ops.ietf.org WG" <namedroppers@ops.ietf.org>
Message-Id: <434ECD68-79BB-45F1-8A68-A4CD8E4A3E11@cisco.com>
From: Patrik Fältström <paf@cisco.com>
To: Ólafur Guðmundsson <ogud@ogud.com>, Andrew Sullivan <ajs@shinkuro.com>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-261-309086428"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Fwd: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time please!
Date: Thu, 27 Aug 2009 06:18:29 +0200
References: <583565A9-886F-41FB-92EA-B9F3E6741A7C@cisco.com>
X-Pgp-Agent: GPGMail d55 (v55, Leopard)
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 27 Aug 2009 04:18:32.0085 (UTC) FILETIME=[6FE41450:01CA26CD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3264; t=1251346766; x=1252210766; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paf@cisco.com; z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20<p af@cisco.com> |Subject:=20Fwd=3A=20[dnsext]=20draft-crocker-dnssec-algo-s ignal-03=20--=20more=20time=20please! |Sender:=20 |To:=20=3D?ISO-8859-1?Q?=3DD3lafur_Gu=3DF0mundsson?=3D=20<o gud@ogud.com>,=0A=20=20=20=20=20=20=20=20Andrew=20Sullivan=2 0<ajs@shinkuro.com>; bh=9Cb6lkwUh8fYls1PqbMZFWAy+xDk0v8I7+vBr2mBhLQ=; b=WC9grPidJG1SJidzAKG6WsKcJJhD8+qVh7V5h8tRqlODSqeFEJ+wzeEAd7 LXKcAGLBeh/JYXMUWepNS65ZjLICyzfe/K65eva39t1tXgew+lktrTxkDNWB 3tTiS3SMJ/;
Authentication-Results: rtp-dkim-1; header.From=paf@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
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/>

So, my final conclusion after talking with people is what I describe  
here. That we before starting accepting drafts that "signal" crypto  
algorithms, we need something stating:

- 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.

In short, people are worried about non-interoperability regarding  
deployment.

So for this document (draft-crocker-dnssec-algo-signal-03) people said  
"I think we should wait...nothing wrong with *this* document, but we  
are missing some pieces in the architecture".

    Patrik

Begin forwarded message:

> From: "Patrik Faltstrom (pfaltstr)" <pfaltstr@cisco.com>
> Date: to 30 jul 2009 09.54.07 GMT+02:00
> To: <namedroppers@ops.ietf.org>
> Subject: [dnsext] draft-crocker-dnssec-algo-signal-03 -- more time  
> please!
>
> A status report...
>
> People are still reaching out to me, and it is pretty clear to me  
> that many people have problems answering yes or no to the question,  
> and that seems to be similar reasons as both yes and no people want  
> to talk so much about the issue.
>
> I will next week summarize in a bit more detail, but it seems people  
> have the feeling that as the overall goal for standards in the IETF  
> is interoperability, and the question is really what impact multiple  
> algorithms have on real life interoperability. How are the  
> algorithms selected? What if everyone "just pick" a favorite? If we  
> are going to have preferred algorithms, how do we shift in and shift  
> out algorithms in that pool (that might have only one entry)? How do  
> we roll over algorithms? Etc...
>
> Everyone (almost) I have talked with think that if we only talked  
> about the real problem, then most certainly one of the things that  
> will be needed is some kind of signalling, for example in the  
> transition from one algorithm to another, but at this point in time  
> -- that is impossible to say.
>
> So at the moment, I see the consensus in the wg is "not yet, we need  
> to work on other documents first, or at least in parallell".
>
> But, I at the same time think I have been contacted by "no" sayers  
> more than "yes" sayers, so I ask the wg chairs for another week of  
> work on what my findings on what the consensus of the wg is.
>
>    Patrik
>