Subject: [TLS] supported_versions in TLS 1.2

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2021 08:36:31 -0700

While working on rfc7525bis [1], we've been pondering [2] whether to 
recommend the "supported_versions" extension for TLS 1.2 (not TLS 1.3) 
implementations. RFC 8446 states:

    -  The "supported_versions" ClientHello extension can be used to
       negotiate the version of TLS to use, in preference to the
       legacy_version field of the ClientHello.

By our reading, it doesn't make any difference to a TLS 1.2 
implementation whether it sends or receives the "supported_versions" 
extension. Corrections welcome, of course! If this is the case, we'd 
prefer not to recommend that TLS 1.2 implementations specifically add 
support for this extension, since upgrading to TLS 1.3 is best anyway.

Thanks,

Peter, Thomas, Yaron

[1] https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/

[2] https://github.com/yaronf/I-D/issues/253

---

From: Hanno Böck <[email-masked]>
Date: Tue, 16 Nov 2021 16:42:48 +0100

On Tue, 16 Nov 2021 08:36:31 -0700

> support for this extension, since upgrading to TLS 1.3 is best anyway.

I have a question about this question:
I think it's generally agreed that TLS 1.3 provides much better
security than TLS 1.2 (that was ultimately why it's been created).

Why would you even write a recommendation for what people should do
with TLS 1.2-only implementations? (I understand this is merely
relevant for implementations not supporting TLS 1.3 at all.) Shouldn't
the recommendation be: "Don't. Please support TLS 1.3." ?

-- 
Hanno Böck
https://hboeck.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Nov 2021 09:14:31 -0700

> the recommendation be: "Don't. Please support TLS 1.3." ?

Well, draft-ietf-uta-rfc7525bis, and RFC 7525 before it, is geared 
toward operators. Although in the bis document we do recommend 1.3 over 
1.2 (and follow RFC 8996 in completely deprecating 1.0 and 1.1), we also 
provide recommendations for how to do support 1.2 most safely before 
upgrading to 1.3. See the Internet-Draft for details and if you have 
feedback on our recommendations, please do post to the [email-masked] list.

Peter

---

From: David Benjamin <[email-masked]>
Date: Tue, 16 Nov 2021 11:33:13 -0500

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.

So, yes, I'd agree there's not much benefit to recommend that a
TLS-1.2-only implementation add supported_versions, or that an operator
look for such an implementation. Any implementation-gated effort is better
spent getting to TLS 1.3.

On Tue, Nov 16, 2021 at 11:14 AM Peter Saint-Andre <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 16 Nov 2021 16:38:50 +0000

*   So, yes, I'd agree there's not much benefit to recommend that a TLS-1.2-only implementation add supported_versions, or that an operator look for such an implementation. Any implementation-gated effort is better spent getting to TLS 1.3.

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. I think the draft might want to separate those two cases.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 17 Nov 2021 07:16:18 +0000

David Benjamin <[email-masked]> writes:

>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

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Nov 2021 14:18:49 +0000

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Nov 2021 13:40:58 -0700

Hi Rich,

> 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 t…

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

---

From: David Benjamin <[email-masked]>
Date: Fri, 19 Nov 2021 16:07:44 -0500

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-masked]>
wrote:

> > 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.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Nov 2021 17:34:02 -0700

Hi David, thanks for your feedback.

On 11/19/21 2:07 PM, David Benjamin wrote:
> 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.)

Already done in our working copy... :-)

https://github.com/yaronf/I-D/pull/258/files

> 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 

Agreed.

On the bright side, just think: eventually we'll publish 7525ter and it 
won't need to talk about TLS 1.2 at all!

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 20 Nov 2021 14:15:08 +0000

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 <[email-masked]>
Date: Friday, November 19, 2021 at 4:08 PM
To: Peter Saint-Andre <[email-masked]>
Cc: Rich Salz <[email-masked]>, Peter Gutmann <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rich,

Am I missing something?

Peter

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Nov 2021 03:45:51 +0000

Salz, Rich <[email-masked]> writes:

>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.

I was making a more general point about not assuming that the only thing that
matters is TLS 1.3 vs. TLS 1.2, and that that's all that needs to be
accommodated.  Because of the TLS family A vs. family B protocol fork, there
will be family A around more or less forever.  For example just a few days ago
I was part of a long conference call with a major global user who was looking
at a minimum 15-year (but in practice I expect more like 20-30 year) support
plan for an upcoming rollout of family A TLS.  So just because TLS 1.3 exists
doesn't mean all work on, and accommodation of, earlier versions should stop.
In particular that's why I wrote the TLS-LTS doc, because that explains how to
apply family A in the safest manner possible for the foreseeable future.

In the specific case of supported_versions, there's no reason why the same
thing can't be used to deal with e.g. TLS 1.0 -> TLS 1.2 version intolerance,
which is still a thing.  That's one thing that SSH did right (alongside a lot
of stuff that TLS does much better), you can fingerprint a server via its ID
string and work around problems when you connect without needing to change the
code on the server you're connecting to.

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Nov 2021 19:59:09 -0800

On Tue, Nov 23, 2021 at 7:46 PM Peter Gutmann <[email-masked]>
wrote:

> Because of the TLS family A vs. family B protocol fork, there
> will be family A around more or less forever.
>

The WG is not obligated to support TLS 1.2.

thanks,
Rob

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 24 Nov 2021 04:03:57 +0000

>The WG is not obligated to support TLS 1.2.

Is that an official WG position, that the TLS WG has abandoned TLS 1.2?  If it
is, can I have change control over it, because if the WG doesn't want to
support it, someone will have to.

(I'm not fussed either way, but would like to see things resolved rather than
just being left in limbo).

Peter.

---

From: Rob Sayre <[email-masked]>
Date: Tue, 23 Nov 2021 20:08:56 -0800

> just being left in limbo).

The charter says "Changes or additions to older versions of (D)TLS whether
via extensions or ciphersuites are discouraged and require significant
justification to be taken on as work items."

I would personally take that to mean "we should fix really bad bugs", but
nothing more. Others may disagree.

I do not think this WG should function as a "permission to use TLS 1.2"
group, because TLS 1.2 shouldn't be used.

ymmv,
Rob

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Nov 2021 15:07:28 +0000

*   I do not think this WG should function as a "permission to use TLS 1.2" group, because TLS 1.2 shouldn't be used.

Strongly disagree.

The Internet is more than just browsers that auto-update yearly. :)  I mean, not even this WG would be willing to put up an RFC that says “TLS 1.2 MUST NOT be used.”  C’mon.

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 24 Nov 2021 11:58:30 -0800

> support it, someone will have to.

To clarify, the TLS WG group is chartered to maintain current and previous versions of (D)TLS, including TLS 1.2. Proposed changes that affect previous versions are therefore in scope.

Best,
Chris, for the chairs

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Nov 2021 13:19:46 -0800

Thanks, Chris.

At a high level, I think we should be focusing our efforts on TLS 1.3.
That means that we should design new features for 1.3 and not for 1.2,
but if it's straightforward to also specify them for 1.2, this is
potentially worthy of consideration on a case-by-case basis.

We generally should not be doing TLS 1.2-only work (including cases
where we have to do a significantly different version or something for
TLS 1.2 and TLS 1.3) except in cases where there is some significant
defect of some kind. I think this is consistent with "maintenance".

-Ekr

On Wed, Nov 24, 2021 at 11:59 AM Christopher Wood <[email-masked]>
wrote:

> To clarify, the TLS WG group is chartered to maintain current and previous
> versions of (D)TLS, including TLS 1.2. Proposed changes that affect
> previous versions are therefore in scope.
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 26 Nov 2021 11:15:00 -0800

I'd also add that it usually takes a few years to publish any RFC, so this
group will increasingly push up against TLS 1.2's deprecation date. There
are already a bunch of caveats one needs to take into account to deploy it
securely, and it seems unlikely we've seen the last attack against it. It's
much more complex than TLS 1.3 in many ways (obv everyone on this email
knows this, just making the point).

SSL 2.0 1995    Deprecated in 2011 (RFC 6176)
SSL 3.0 1996    Deprecated in 2015 (RFC 7568)
TLS 1.0 1999    Deprecated in 2020 (RFC 8996)
TLS 1.1 2006    Deprecated in 2020 (RFC 8996)
TLS 1.2 2008    Deprecated in ????
TLS 1.3 2018

At the limit, this group could specify extensions to TLS 1.2 that would
exist as published RFCs for a very short period of time before TLS 1.2 is
deprecated. I don't feel strongly about the extension that sparked this
discussion, but TLS 1.2 efforts of any kind become more questionable with
the passage of time.

thanks,
Rob

>> To clarify, the TLS WG group is chartered to maintain current and
>> previous versions of (D)TLS, including TLS 1.2. Proposed changes that
>> affect previous versions are therefore in scope.
>>
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Nov 2021 20:06:11 +0000

> but TLS 1.2 efforts of any kind become more questionable with the passage of time.

What part of TLS 1.2 will become questionable that would not also affect TLS 1.3?  I mean, you can configure 1.2 with just about the same cipher suites.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 29 Nov 2021 18:29:35 +0000

Perhaps I missed some part of this thread, but it's still not clear to me what would be the purpose of adding supported_versions extension to a TLS 1.2 implementation? What problem(s) would that solve?

Cheers,

Andrei

From: TLS <[email-masked]> On Behalf Of Rob Sayre
Sent: Friday, November 26, 2021 11:15 AM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [TLS] supported_versions in TLS 1.2

I'd also add that it usually takes a few years to publish any RFC, so this group will increasingly push up against TLS 1.2's deprecation date. There are already a bunch of caveats one needs to take into account to deploy it securely, and it seems unlikely we've seen the last attack against it. It's much more complex than TLS 1.3 in many ways (obv everyone on this email knows this, just making the point).

At the limit, this group could specify extensions to TLS 1.2 that would exist as published RFCs for a very short period of time before TLS 1.2 is deprecated. I don't feel strongly about the extension that sparked this discussion, but TLS 1.2 efforts of any kind become more questionable with the passage of time.

thanks,
Rob

On Wed, Nov 24, 2021 at 1:20 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Chris.

-Ekr

On Wed, Nov 24, 2021 at 11:59 AM Christopher Wood <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Nov 23, 2021, at 8:03 PM, Peter Gutmann wrote:
> Rob Sayre <[email-masked]<mailto:[email-masked]>> writes:
>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C7fa3aee16e3f4948bfa308d9b11122d7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637735509927018490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uLY4phjepSXvS2x3W5GsV%2FURH0o0BcaNRgtmU5a%2BcSg%3D&reserved=0>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 13:39:54 -0700

On 11/29/21 11:29 AM, Andrei Popov wrote:
> Perhaps I missed some part of this thread, but it’s still not clear to 
> me what would be the purpose of adding supported_versions extension to a 
> TLS 1.2 implementation? What problem(s) would that solve?

Based in part on discussion here, we (the authors of 6125bis) concluded 
[1] that we don't need to recommend adding the supported_versions 
extension to TLS 1.2-only implementations.

If folks find that decision problematic, do let us know.

Peter

[1] https://github.com/yaronf/I-D/issues/253

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 29 Nov 2021 23:49:28 +0200

On 11/29/21, 22:40, "Peter Saint-Andre" <[email-masked]> wrote:

Typo: should be 7525bis (the TLS BCP).

Peter

TLS mailing list

[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Nov 2021 15:01:48 -0700

> Typo: should be 7525bis (the TLS BCP).

Sorry about that, I'm working on both at the same time. :-)

Peter