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

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 09 November 2009 18:36 UTC

Return-Path: <Nicolas.Williams@sun.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 E87523A6359 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 10:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.017
X-Spam-Level:
X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 s8L1de4g3Hj8 for <tls@core3.amsl.com>; Mon, 9 Nov 2009 10:36:47 -0800 (PST)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id DC0423A659C for <tls@ietf.org>; Mon, 9 Nov 2009 10:36:41 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA9Ib3l3020085 for <tls@ietf.org>; Mon, 9 Nov 2009 18:37:03 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA9Ib3Ht054507 for <tls@ietf.org>; Mon, 9 Nov 2009 11:37:03 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9II15N011755; Mon, 9 Nov 2009 12:18:01 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9II1bk011754; Mon, 9 Nov 2009 12:18:01 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 09 Nov 2009 12:18:01 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Eric Rescorla <ekr@networkresonance.com>
Message-ID: <20091109181800.GD1105@Sun.COM>
References: <1b587cab0911080935m64eabca8t6f7f6dfb9a666d06@mail.gmail.com> <p06240806c71ce60888e1@[133.93.128.35]> <4AF73817.4080802@extendedsubset.com> <20091108231234.4A72569E39E@kilo.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20091108231234.4A72569E39E@kilo.networkresonance.com>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org, Paul Hoffman <paul.hoffman@vpnc.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 18:36:48 -0000

On Sun, Nov 08, 2009 at 03:12:34PM -0800, 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?

I think we need emergency allocation procedures.  If, for the sake of
argument, your I-D should fail to become a Proposed Standard, then any
allocations made for it would become historical.

I think now would be a fine time to make an emergency allocation and set
the precedent.  A subsequent document outlining emergency allocation
procedures for the IETF and IANA would be a good thing to have.

Not only do we need emergency allocations, but also confidentiality
until the time is right for public disclosure.  This last is bound to be
somewhat controversial, I'm sure.  But then, I think too that
implementors can probably manage to fix allocations reasonably late in
the process IF the process of fixing a protocol vulnerability is not too
long.

Nico
--