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

From: Ben Laurie <[email-masked]>
Date: Sun, 8 Nov 2009 17:35:29 +0000

I have just committed an implementation of
https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt
to the head of the 0.9.8-stable tree of OpenSSL.

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?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Nov 2009 06:19:03 +0900

>do we get a real one allocated?

When an extension goes on Standards Track, it can get an extension number.

--Paul Hoffman, Director
--VPN Consortium

---

From: Marsh Ray <[email-masked]>
Date: Sun, 08 Nov 2009 15:28:55 -0600

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

- Marsh

---

From: Florian Weimer <[email-masked]>
Date: Sun, 08 Nov 2009 23:27:08 +0100

> When an extension goes on Standards Track, it can get an extension

The registry requires "IETF consensus".  Does this really imply a
standards track RFC?

---

From: Russ Housley <[email-masked]>
Date: Sun, 08 Nov 2009 20:50:34 -0500

>The registry requires "IETF consensus".  Does this really imply a

No.  It means there must be an IETF Last Call.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 08 Nov 2009 15:12:34 -0800

At Sun, 08 Nov 2009 15:28:55 -0600,
> 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?

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Nov 2009 13:28:45 +0900

>No.  It means there must be an IETF Last Call.

Sorry, Russ is correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 09 Nov 2009 16:13:45 +0000

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

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 09 Nov 2009 09:59:53 -0800

At Mon, 09 Nov 2009 16:13:45 +0000,
> 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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Nov 2009 12:18:01 -0600

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Nov 2009 06:56:17 +0900

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

Right: the problem is determining what that code point means. If there is an early assignment of code point Foo for draft-ietf-tls-frigmo-00.txt, and there is a bits-on-the-wire change in -01, what does Foo mean? Implementers will split between "it means the -00, get another code point" and "it means the latest version only".

If you think this is a simple problem, you haven't seen the ragged history of the IETF in this regard.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 10:26:24 +0100

Eric Rescorla wrote:

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

<wearing area director hat>

I think this is one of those cases where an exception to the usual
procedures might be in order, but the "once the WG has converged on
the exact contents" is an important point here. It's relatively rare
that the -00 version of some internet draft and the final RFC are
actually interoperable.

Using the same extension number for multiple incompatible versions of
the draft is probably not a good idea (and probably not very secure,
either -- if the handshake fails, you don't know if it's due to an
attack or just interoperability problem, and the latter might be much
more likely), and I'd like to avoid allocating multiple extension
numbers for different versions of the draft, too.

I certainly hope the WG converges on the contents relatively fast.
The TLS WG is meeting tomorrow (Thursday), so we'll see soon.

Best regards,
Pasi

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 11 Nov 2009 18:59:33 +0000

> numbers for different versions of the draft, too.

Would including a version number in the extension help? Then if the format does
change implementations can indicate that it is a version they don't support or
decide they are willing to support an older version.

This would also cover the case where some cryptographic attack is found against
the current form later. We keep the extension number but bump up the version.

Steve.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 12 Nov 2009 00:14:56 +0000

>> that the -00 version of some internet draft and the final RFC are

It's rare for typical RFCs, but this is a very simple extension. The
discussion so far has been about when clients and servers MUST or SHOULD
send the extension; not about changes to its contents or meaning that
would affect interoperability. If no such changes in fact occur, then I
would hope that the existing extension number (0xFF01) could be assigned,
rather than assigning a new number for the sake of it.

> decide they are willing to support an older version.

I don't see any advantage of that over using a different extension number,
*if* the format changes.

In any case, the current draft is -00, and no changes that would not
be interoperable have yet been proposed. So let's avoid prematurely
adding complication where it may not be needed.

> the current form later. We keep the extension number but bump up the version.

Adding a new extension would have the same effect.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Nov 2009 08:09:06 +0200

At Wed, 11 Nov 2009 18:59:33 +0000,
> the current form later. We keep the extension number but bump up the version.

I considered that, but I'm not sure it really helps. Once the initial version
is widely supported you need to send the old version as well as the new
version for a smooth transition. Might as well have two extension code
points.

-Ekr