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 protected]> On Behalf Of Rob Sayre
Sent: Friday, November 26, 2021 11:15 AM
To: Eric Rescorla <[email protected]>
Cc: [email protected]
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).

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



On Wed, Nov 24, 2021 at 1:20 PM Eric Rescorla 
<[email protected]<mailto:[email protected]>> wrote:
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 protected]<mailto:[email protected]>> wrote:
On Tue, Nov 23, 2021, at 8:03 PM, Peter Gutmann wrote:
> Rob Sayre <[email protected]<mailto:[email protected]>> writes:
>
>>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.

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.



_______________________________________________
TLS mailing list
[email protected]<mailto:[email protected]>
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>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to