Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Implementing https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegot iate.txt
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
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.