Re: [TLS] supported_versions question

[Dave Garrett <[e-mail]>]

On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> On 31/10/16 23:53, Dave Garrett wrote:
> >> I came up with some alternative wording that I think captures the discussion:
> >>
> >> 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.
> 
> 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?

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