Re: [TLS] supported_versions in TLS 1.2

["Salz, Rich" <[e-mail]>]

Peter has forgotten more about long-term embedded applications than the rest of us have experience. I’ll leave it to him to say why it’s important.

From: David Benjamin <[e-mail]>
Date: Friday, November 19, 2021 at 4:08 PM
To: Peter Saint-Andre <[e-mail]>
Cc: Rich Salz <[e-mail]>, Peter Gutmann <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] supported_versions in TLS 1.2

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 <[e-mail]<mailto:[e-mail]>> 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