David Benjamin <david...@google.com> wrote:
> Ilari Liusvaara <ilariliusva...@welho.com> wrote:
>
>> The case where legacy_version < TLS1.2 IIRC isn't specified, but
>> ignoring legacy_version is reasonable in this case too.
>>
>
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.
> 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 [two] 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'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/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
