Subject: [TLS] PR#634: Registry for TLS protocol version ID

From: Sean Turner <[email-masked]>
Date: Wed, 12 Oct 2016 18:26:06 -0400

Al,

David Garrett has generated PR#634 (https://github.com/tlswg/tls13-spec/pull/634) to "explicitly [rename] the protocol version fields as IDs and defines a registry for all values, as they're really just arbitrary codepoints at this point.”  Note that there are no bits on the wire changes as result of this PR, but it does establish more process; if we’re publishing a new TLS version there’s already be lots of process this won’t be the straw that breaks the camel’s back.  We’d like to get a sense as to whether this PR should be merged - please provide any comments on merging this PR by Friday (10/14).

J&S

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Oct 2016 22:49:22 +0000

> David Garrett has generated PR#634 (https://github.com/tlswg/tls13-
> spec/pull/634)

+1

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2016 16:00:34 -0700

On Wed, Oct 12, 2016 at 3:26 PM, Sean Turner <[email-masked]> wrote:

> Al,
>
> David Garrett has generated PR#634 (https://github.com/tlswg/
> tls13-spec/pull/634) to "explicitly [rename] the protocol version fields
> as IDs and defines a registry for all values, as they're really just
> arbitrary codepoints at this point.”  Note that there are no bits on the
> wire changes as result of this PR, but it does establish more process; if
> we’re publishing a new TLS version there’s already be lots of process this
> won’t be the straw that breaks the camel’s back.  We’d like to get a sense
> as to whether this PR should be merged - please provide any comments on
> merging this PR by Friday (10/14).
>
>
This PR involves two changes:

1. Attaching the term "ID" to version and defining new enum code points.
2. Creating a registry

The first of these seems obfuscatory and unhelpful. The second just seems
unnecessary. Other specifications other than new versions of TLS won't be
adding new code points, so I don't see how a registry helps.

I would prefer we not merge this PR.

-Ekr

J&S
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Oct 2016 11:55:10 +1100

> I would prefer we not merge this PR.

I concur, though I would prefer if we stopped using the strange { 3, 3
} notation for versions, it's not useful and it implies a significance
to the separation that just doesn't exist*.

[*] One caveat: you will likely be very sad if you try to change that
first octet in a ClientHello.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 12 Oct 2016 20:59:15 -0400

> I would prefer we not merge this PR.

One added feature we get with this registry definition is a range of codepoints for private experimental use. Formal definition might not be strictly needed here, though it shouldn't hurt.

My reasoning for the explicit use of "ID" is that it would be more clear to use the term "version ID" to refer to the arbitrary codepoints (e.g. 0x0304) and simply "version number" to refer to the more descriptive "TLS 1.3". Both do end up on-the-wire; the former in the version fields and the later in context strings, which is one of the reasons why I think being more explicit here may be a good idea.

The registry was first suggested by Daniel Kahn Gillmor in prior mailing list discussion around rebranding to TLS 2.0 (which we're treating as a separate issue, at the moment). I think it makes sense and I would prefer it be merged, but I don't ascribe very high importance here.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Oct 2016 12:05:19 +1100

> One added feature we get with this registry definition is a range of codepoints for private experimental use. Formal definition might not be strictly needed here, though it shouldn't hurt.

The same can be achieved by saying "future versions of TLS will not
use version numbers higher than 0x3fff; values with the top bit set
are reserved for legacy versions of DTLS; values with the two bits set
to 01 are reserved for experimentation".  We don't need IANA to look
after that.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2016 18:07:00 -0700

> to the separation that just doesn't exist*.

I assume you would prefer hex, i.e., 0x0303?

> first octet in a ClientHello.

Indeed.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Oct 2016 12:10:21 +1100

> I assume you would prefer hex, i.e., 0x0303?

Yeah, that would be nice: it's recognizably the same as the old one that way.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Oct 2016 18:03:00 -0700

Chairs: Can you advise on the disposition of this?

-Ekr

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 18 Oct 2016 12:59:59 -0700

It doesn't look like we have enough consensus to adopt this proposal.

Thanks,

J&S