Eric Rescorla <e...@rtfm.com> wrote:
> Brian Smith <br...@briansmith.org> wrote:
>> Ilari Liusvaara <ilariliusva...@welho.com> wrote:
>>> Omitting TLS 1.2 causes failures in some downnegotiation cases (when
>>> are higher versions supported, but not overlapping).
>> 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.
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.
TLS mailing list