Subject: [TLS] supported_versions question

From: Matt Caswell <[email-masked]>
Date: Mon, 31 Oct 2016 18:43:52 +0000

A few supported_versions questions:

1) What should a server do if supported_versions is received but
ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
ignore legacy_version?

2) What should a server do if supported_versions is received,
ClientHello.legacy_version == TLS1.2, but supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 31 Oct 2016 20:57:24 +0200

> ClientHello.legacy_version != TLS1.2? Fail the handshake, or just

If legacy_version > TLS1.2, the spec requires server to ignore
legacy_version.

The case where legacy_version < TLS1.2 IIRC isn't specified, but
ignoring legacy_version is reasonable in this case too.

> handshake, use the legacy_version, or use use the versions in

There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
the latter the server has never heard about...

> the client talks to a server that doesn't understand

Yeah, I presume putting the version in legacy_version is the only sane
thing to do. But causes other problems with downgrade protection.

OTOH, RSA key exchange is known to be very broken and is affected by
all kinds of downgrade (and other) attacks. So if one wants actual
security, it needs to be removed.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Mon, 31 Oct 2016 19:11:10 +0000

> security, it needs to be removed.

We could say the versions extension only applies to 1.2 and up. I.e. don't
bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
when they see them in the version list. That keeps the protocol deployable
on the Internet as it exists, avoids having to evaluate too versioning
schemes (if you see the extension, you don't bother reading legacy_version
at all), while avoiding the weird behavior where, given this ClientHello:

   legacy_version: TLS 1.2
   supported_versions: {TLS 1.1}

TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

David

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 31 Oct 2016 21:30:10 +0200

> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

Yeah, I don't think it ever makes sense to stick TLS 1.0 or 1.1 into
supported_versions. There are good reasons to stick TLS 1.2 there tho.

-Ilari

---

From: Xiaoyin Liu <[email-masked]>
Date: Mon, 31 Oct 2016 19:33:36 +0000

I think for question 1, it should ignore legacy_version, and select a version from supported_versions, because if a client only supports TLS 1.1 and TLS 1.3, in order to connect to pre-TLS1.3 server, it has to set legacy_version to TLS 1.1.

I have no idea about questions 2 or 3.

Best,

Xiaoyin

From: Matt Caswell<mailto:[email-masked]>
Sent: Monday, October 31, 2016 2:44 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] supported_versions question

Matt

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

---

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

David Benjamin <[email-masked]> wrote:

> Ilari Liusvaara <[email-masked]> wrote:
>
I imagine that there will be three common implementations for the case
where legacy_version < 1.2 and supported_versions is present:

1. The server ignores supported_versions. (Note that all TLS 1.0 and TLS
1.1 implementations will do this.)
2. The server ignores legacy_version and only looks at supported_versions.
3. The server drops the connection (maybe with an alert) because clients
shouldn't be doing that in the first place.

> on the Internet as it exists, avoids having to evaluate [two] versioning

David's suggestion here is reasonable and good. It definitely would be
surprising and unwanted to allow supported_versions to negotiate anything
less than TLS 1.2, especially when legacy_version is TLS 1.2.

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

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 31 Oct 2016 23:20:58 +0100

> supported_versions. There are good reasons to stick TLS 1.2 there tho.

Can you give some more details about those good reasons?

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 31 Oct 2016 23:34:31 +0100

> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.

Kurt

---

From: David Benjamin <[email-masked]>
Date: Mon, 31 Oct 2016 23:13:12 +0000

On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <[email-masked]> wrote:

Hrm, actually I hadn't thought of that. Yeah, I guess a server which
disables versions must then gate supported_version handling on whether TLS
1.3 is enabled. That's not a dealbreaker, but is certainly additional
gnarliness.

(Our current implementation just processes the extension uncondtionally,
but we'll also happily negotiate old versions out of it.)

David

---

From: Matt Caswell <[email-masked]>
Date: Mon, 31 Oct 2016 23:26:30 +0000

On 31 October 2016 at 23:13, David Benjamin <[email-masked]> wrote:
> (Our current implementation just processes the extension uncondtionally, but
> we'll also happily negotiate old versions out of it.)

I came up with some alternative wording that I think captures the discussion:

https://github.com/tlswg/tls13-spec/pull/748

Matt

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Oct 2016 16:35:10 -0700

Our current implementation also processes the extension unconditionally.

I'm not convinced that this represents an improvement, both for the reason
that Kurt
indicates and just in terms of simplicity of story. The current design is
simply
"if supported_versions is present, then use it", whereas trying to clip it
on 1.2
is inherently more complicated. I'm not particularly bothered by the anomaly
that David mentions between legacy_version and supported_versions,
especially
given that we're perfectly happy to tolerate deviation the other way.

-Ekr

---

From: Matt Caswell <[email-masked]>
Date: Mon, 31 Oct 2016 23:49:31 +0000

> given that we're perfectly happy to tolerate deviation the other way.

My biggest concern is that there are a number of corner cases here
where it is unclear what to do because the current wording doesn't
specify it (see my original questions at the start of this thread).
Like, I said earlier, it could be made to work If retaining <TLS1.2 in
supported_versions is desirable, but in that case we need to specify
how we should treat legacy_version and what to do if it isn't 0x0303 -
and in the RSA key exchange case which client_version are we using?

Matt

---

From: Dave Garrett <[email-masked]>
Date: Mon, 31 Oct 2016 19:53:25 -0400

> https://github.com/tlswg/tls13-spec/pull/748

I see no reason to require servers to validate the legacy version value. That's just excess complexity. If the extension is there, then it should take absolute precedence. If not, use the old system. Nothing will have a higher value there except old probers.

Ditching TLS 1.0/1.1 from the extension sounds fine, though. There's not going to be any servers accepting this extension that won't negotiate 1.2+.

Dave

---

From: Matt Caswell <[email-masked]>
Date: Tue, 1 Nov 2016 00:05:59 +0000

> I see no reason to require servers to validate the legacy version value. That's just excess complexity. If the extension is there, then it should take absolute precedence. If not, use the old syste…

If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
0x0303 (TLS1.2) - or vice versa, which client_version should be used
in an RSA key exchange calculation?

Matt

---

From: Dave Garrett <[email-masked]>
Date: Mon, 31 Oct 2016 20:19:15 -0400

> in an RSA key exchange calculation?

Why would this ever happen? What client is offering to support TLS 1.1 via the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? This is a very contrived implementation error; if you need to account for it, abort the connection with an error. As to the vice versa, dropping 1.0/1.1 support from the extension avoids that.

The simplest route here is to always use the extension if it exists, and use the legacy value if not. With 1.0/1.1 removed from the extension, that means that 1.0/1.1 cannot be negotiated with the extension, which I see as fine; they'll only be negotiated with servers that don't support the extension. (the theoretical case of a server wanting to negotiate 1.0/1.1 with a client using the extension is not one worth supporting; 1.2+ or bust is reasonable, here)

Dave