Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt

Eric Rescorla <ekr@networkresonance.com> Mon, 09 November 2009 17:58 UTC

Return-Path: <ekr@networkresonance.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0F43A6948 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 09:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.04
X-Spam-Level:
X-Spam-Status: No, score=0.04 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=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 4c6pbR4XUXBa for <tls@core3.amsl.com>; Mon, 9 Nov 2009 09:58:48 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0B3443A6945 for <tls@ietf.org>; Mon, 9 Nov 2009 09:58:48 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 8DF8F69E5CB; Mon, 9 Nov 2009 09:59:54 -0800 (PST)
Date: Mon, 09 Nov 2009 09:59:53 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Dr Stephen Henson <lists@drh-consultancy.demon.co.uk>
In-Reply-To: <4AF83FB9.9060302@drh-consultancy.demon.co.uk>
References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <p06240806c71ce60888e1@[133.93.128.35]> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com> <4AF83FB9.9060302@drh-consultancy.demon.co.uk>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20091109175954.8DF8F69E5CB@kilo.networkresonance.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 17:58:49 -0000

At Mon, 09 Nov 2009 16:13:45 +0000,
Dr Stephen Henson wrote:
> 
> Eric Rescorla wrote:
> > At Sun, 08 Nov 2009 15:28:55 -0600,
> > Marsh Ray wrote:
> >> Paul Hoffman wrote:
> >>> At 5:35 PM +0000 11/8/09, Ben Laurie wrote:
> >>>> At some point soon, I guess we'll be releasing an update. It'd be good
> >>>> not to consume an experimental extension number in the process - how
> >>>> do we get a real one allocated?
> >>> When an extension goes on Standards Track, it can get an extension number.
> >> The world is not going to wait in a vulnerable state very long. There is
> >> an experimental extension number already sitting in multiple source
> >> trees, ready to ship. Ben has asked nicely.
> >>
> >> If the relevant committees prefer that a different number be used,
> >> they'd better speak up soon.
> > 
> > I'm a bit biased because I'm the author of this draft, but
> > I really don't see a problem with getting a reservation for
> > a number out of a 16 bit space nowish. Joe? Pasi/Tim?
> > 
> 
> Can this not be handled as a special case since the circumstances are clearly
> exceptional? For example saying in advance what number it will get when
> everything is done officially?

I don't think the problem here is really the code point assignment.

I would imagine the IESG and IANA to be pretty good about doing
advance assignments once the WG has converged on the exact
contents of the extension. I know we had pretty good consensus
within a smaller group, but if when we run it by some cryptographers
they say it's insecure we'll need to change it, at which point
it won't really help to have deployed code with the "early" code
point.

-Ekr