David Benjamin <[email protected]> writes: >The operators themselves are probably not in a position to either implement >supported_versions or not in TLS 1.2. If an operator, for whatever reason, >only has a TLS 1.2 implementation on hand, it presumably predates TLS 1.3 and >thus does not implement supported_versions. If it implements >supported_versions, it presumably postdates TLS 1.3 and the operator should >enable the TLS 1.3 bit.
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 indefinite amount of time, years if not decades. So it makes perfect sense to define things for TLS A as well as TLS B because, like the HTTP 1.x vs. HTTP 2.x fork, the A family could well be around forever for situations where users don't want to switch over to a second protocol, in the same way that HTTP 1.x will be with us forever. So it makes perfect sense to keep defining new mechanisms for TLS family A alongside TLS family B. Peter. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
