Subject: [TLS] Supported Versions extension

From: Hubert Kario <[email-masked]>
Date: Mon, 17 Oct 2016 18:37:02 +0200

Currently the description of the extension states that only TLS versions can 
be listed in the extension and all unknown versions must be ignored.

I wonder if making it explicit that {3, 0} and any lower values MUST NOT be 
advertised wouldn't be a good idea, if only to hammer it that SSL3 must not be 
used.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Brian Smith <[email-masked]>
Date: Mon, 17 Oct 2016 10:25:07 -1000

> advertised wouldn't be a good idea, if only to hammer it that SSL3 must

AFAICT, there's no need to list any version in that extension lower than
TLS 1.2, and maybe not even TLS 1.2. If the server understand the extension
then it is (almost?) definitely a TLS 1.3+ implementation, so it should
choose TLS 1.3 or later. If the server doesn't understand the extension
then it will use the ClientHello.legacy_version field for version
negotiation.

Therefore, I suggest the following change:

OLD: "Implementations of this specification MUST send this extension
containing all versions of TLS which they are prepared to negotiate. For
this specification, that means minimally {3, 4}, but if previous versions
of TLS are supported, they MUST be present as well."

NEW: "Implementations of this specification MUST send this extension
containing all versions of TLS from TLS 1.3 onwards (only) which they are
prepared to negotiate. For this specification, that means minimally {3, 4}.
If previous versions of TLS are supported, they MUST NOT be present."

Cheers,
Brian

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Oct 2016 23:37:41 +0300

> If previous versions of TLS are supported, they MUST NOT be present."

Omitting TLS 1.2 causes failures in some downnegotiation cases (when there
are higher versions supported, but not overlapping).

OTOH, negotiating 1.0 or 1.1 with this extension supported at both sides
is very unlikely.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Mon, 17 Oct 2016 10:40:31 -1000

> are higher versions supported, but not overlapping).

Could you provide a concrete example, please?

Thanks,
Brian
--
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Oct 2016 16:42:39 -0400

> Could you provide a concrete example, please?

When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and TLS
1.3 draft-17.

I would prefer to stick with the current design where if supported_versions
exists it is the sole
mechanism for negotiation.

-Ekr

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

---

From: Brian Smith <[email-masked]>
Date: Mon, 17 Oct 2016 12:49:30 -1000

Eric Rescorla <[email-masked]> wrote:

> Brian Smith <[email-masked]> wrote:
>
> When I support TLS 1.2 and TLS 1.3 draft-16 and you support TLS 1.2 and
> TLS 1.3 draft-17.
>

> exists it is the sole mechanism for negotiation.
>

Note that in my suggestion, supported_versions is the sole mechanism for
negotiation as well. With my suggestion, in your example where two
different TLS 1.3 drafts are supported, by each end, the server will see
that no supported draft of TLS 1.3 is supported and then negotiate TLS 1.2
if it supports TLS 1.2; otherwise it would give up. It can make this
decision purely based on the contents of the supported_versions extension.
Then if the client supports TLS 1.2 it will continue; otherwise it will
abort. So there doesn't seem to be a significant benefit to advertising TLS
1.2 support in the extension.

Especially since TLS 1.2 is a superset of TLS 1.1 and TLS 1.0, I don't
think there's any need for  TLS 1.0 or TLS 1.1 to be mentioned in the
extension at all, even if the client supports them, because a server that
supports this extension shouldn't ever negotiate TLS 1.0 or TLS 1.1.
Imagine that we wanted to support clients that support TLS 1.0 and/or TLS
1.1, not TLS 1.2, but TLS 1.3, for some reason. Then we'd need to allow the
legacy_version field to be TLS 1.1 or TLS 1.0. But, I don't think it's
useful to support this.

Cheers,
Brian