I think that's right. There's not much benefit to adding supported_versions to a TLS-1.2-only stack. We introduced it in TLS 1.3 because of compatibility issues and because it was more flexible and less prone to compatibility issues going forward. The forward-looking benefits don't really apply here (TLS 1.2 has already been updated as TLS 1.3), and TLS 1.2 version intolerance was (painstakingly) cleared out already. (To that end, I'd suggest changing Section 3.1.3 of rfc7525bis. The old insecure version fallbacks are no more.)
There's nothing *wrong* with implementing supported_versions in TLS 1.2. It's, in fact, one of the steps in implementing TLS 1.3. It's just not very useful beyond that. Thus, in a document of recommendations for TLS 1.2 operators, there's no need to include it. (Note the absence of a recommendation doesn't mean we recommend against it.) On Fri, Nov 19, 2021 at 3:41 PM Peter Saint-Andre <[email protected]> wrote: > 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
