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
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.