Subject: [TLS] Remove deprecated fields in TLS 1.3

From: Arnaud Venturi <[email-masked]>
Date: Sun, 2 Apr 2017 18:33:02 +1000

Hello everybody,

Here is a proposal for change aiming at removing the deprecated fields
in ClientHello in a future TLS version.

This proposal would consist in changing the ClientHello structure from :

  struct {
      ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
      Random random;
      opaque legacy_session_id<0..32>;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^8-1>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

to :

  struct {
      ProtocolVersion legacy_version;
      Random random;
      select (ClientHello.legacy_version) {
        case 0x0303:    /* TLS v1.2 */
          opaque legacy_session_id<0..32>;
          CipherSuite cipher_suites<2..2^16-2>;
          opaque legacy_compression_methods<1..2^8-1>;
        case 0x0304:    /* TLS v1.3 */
          CipherSuite cipher_suites<2..2^16-2>;
      }
      Extension extensions<8..2^16-1>;
  } ClientHello;

With the following constraints :
- TLS 1.3 Servers MUST correctly parse ClientHello with
ClientHello.legacy_version either set to 0x0303 (TLS1.2) or 0x0304
(TLS1.3), and MUST NOT use this field's value for any other purpose than
parsing the ClientHello (notably, il MUST NOT be used to negociate the
protocol version, this is the role of the SupportedVersions Extension)
- TLS 1.3 Clients MUST set ClientHello.legacy_version either to 0x0303
(TLS1.2) or 0x0304 (TLS1.3)
- TLS 1.3 Clients SHOULD set ClientHello.legacy_version to 0x0303 (TLS1.2)
- TLS 1.3 Clients MAY set ClientHello.legacy_version to 0x0304 (TLS1.3)
present knowledge that the server supports TLS 1.3.

The idea is to use the legacy_version field to indicate the ClientHello
structure, rather than just being a deprecated field.

This way, a future release may only allow the 0x0304 value for
ClientHello.legacy_version without breaking compatibility with TLS 1.3
implementations.
This would be a reasonable change once TLS 1.2 is completely phased out,
or deemed too insecure to be used anymore.
It would then allow switching the ClientHello structure to :

  struct {
      ProtocolVersion legacy_version = 0x0304;    /* TLS v1.3 */
      Random random;
      CipherSuite cipher_suites<2..2^16-2>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

I kept the name legacy_version in this email for the sake of clarity,
but if it is decided to make such a change, it would probably be
pertinent to rename it.
client_hello_version, for example, might be a viable candidate.

A few other notes about the implications of such a change :
- The client side of the implementation is completely unchanged by this
modification
- The modifications to do to server implementations are minor, and not
likely to present any difficulty
- The current deprecated fields are not likely to be ever used again in
the future. If we need to add anything to the ClientHello, we would
likely use Extensions regardless of the presence or not of these
deprecated fields.

I could not think of any security or interoperability issue with this
proposal, the only drawback I can see being the slight complexity added
in ClientHello parsing.

I'll be really happy to formalize this proposal in a pull request, or to
clarify any unclear point, but I wanted to gather some opinions on the
topic before going further.

-- 
Arnaud

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 2 Apr 2017 23:29:16 -0500

> proposal, the only drawback I can see being the slight complexity added

The ClientHello message needs to be interpreted in the same way by TLS
servers running all versions of TLS.  A TLS 1.0 server would not know to
use the changed interpretation of the fields and would fail to negotiate
a connection.  Basically, no change in the format is possible while
preserving the backwards and forwards compatibility of version negotiation.

-Ben

---

From: David Benjamin <[email-masked]>
Date: Mon, 03 Apr 2017 16:36:39 +0000

On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <[email-masked]> wrote:

> use the changed interpretation of the fields and would fail to negotiate a
> connection.  Basically, no change in the format is possible while

I believe the idea is that, if you support TLS 1.2 and below, you send a
1.2-compatible ClientHello. If you don't, then you send the proposed
ClientHello. Servers would be required to support both formats.

This change would save us all of 3 bytes in the ClientHello, so my feeling
is this isn't worth the trouble of having two formats and all the trouble
that entails. (Servers having to parse both formats, code in servers that
won't be exercised for years, clients worrying about whether servers
implemented that, etc.)

David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Apr 2017 10:10:42 -0700

I agree with David. This seems like a low value change

On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin <[email-masked]> wrote:

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

---

From: Arnaud Venturi <[email-masked]>
Date: Tue, 4 Apr 2017 18:58:33 +1000

This was infact the idea, even I thought of the gain much more in terms
of removing something useless than in gaining a few bytes.

Anyway, thanks for your opinions and your time !

-- 
Arnaud

On 04/04/2017 03:10 AM, Eric Rescorla wrote:
> On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         The ClientHello message needs to be interpreted in the same
>         way by TLS servers running all versions of TLS.  A TLS 1.0
>         server would not know to use the changed interpretation of the
>         fields and would fail to negotiate a connection.  Basically,
>         no change in the format is possible while preserving the
>         backwards and forwards compatibility of version negotiation.
>
>
>     I believe the idea is that, if you support TLS 1.2 and below, you
>     send a 1.2-compatible ClientHello. If you don't, then you send the
>     proposed ClientHello. Servers would be required to support both
>     formats.
>
>     This change would save us all of 3 bytes in the ClientHello, so my
>     feeling is this isn't worth the trouble of having two formats and
>     all the trouble that entails. (Servers having to parse both
>     formats, code in servers that won't be exercised for years,
>     clients worrying about whether servers implemented that, etc.)
>
>     David
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>