Hi Rich,
On 11/17/21 7:18 AM, Salz, Rich wrote:
Peter has said it more colorfully than I have:
Not necessarily. Since TLS 1.3 has forked TLS into two protocols, 1.0-1.2
and
1.3 (lets call them TLS family A and TLS family B), there are a large
number
of users who will be sticking with the TLS A rather than TLS B family for
an
But he is right. At least Amazon, CloudFlare, and Facebook have had implementations of
TLS 1.3 that handed off the connection to "legacy code" if it was an earlier
version. (Of course, I don't know if they still do that.)
To repeat myself from yesterday: "I agree that if you have supported_versions than
you probably also have a 1.3-capable stack. But it is also possible to have the first
without the second." And to be more direct: the draft SHOULD separate those two
cases.
I think 7525bis does separate the two cases. To me the question is
whether we achieve anything by that a 1.2-only stack should implement
the "supported_versions" extension. Here's my reasoning (please do
correct me if I'm wrong)...
With regard to a TLS 1.2-only client, by my reading RFC 8446 says:
- if the client does not send the supported_versions extension then a
server that supports both 1.2 and 1.3 will negotiate 1.2
- if the client does not send the supported_versions extension then
presumably the value of that extension and of the legacy_version field
will both be set to 0x0303, in which case again a server that supports
both 1.2 and 1.3 will negotiate 1.2
Ergo: why should a 1.2-only client add support for the
supported_versions extension?
With regard to a TLS 1.2-only server, by my reading RFC 8446 says:
- if the server receives the supported_versions extension and it
supports the extension, it will only negotiate 1.2 because it doesn't
support 1.3
- if the server receives the supported_versions extension (say, from a
1.3 client) but doesn't support the extension, then it will negotiate 1.2
Ergo: why should a 1.2-only server add support for the
supported_versions extension?
Am I missing something?
Peter
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
