Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrwJHjO8c5IFN-JZ@dojo.mi.org>
Date: Tue, 13 Aug 2024 21:32:14 -0400
From: "Mike O'Connor" <mjo@...o.mi.org>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS
 1.0/1.1

:OpenSSL is currently considering the deprecation of the TLS 1.0/1.1
:protocols.  Currently TLS1.1 and TLS 1.0 are disabled at run time, and
:requires enablement by reducing the ssl security level value.
:
:The current proposal under consideration is to explicitly disable TLS
:1.0/1.1 at build time, in our 4.0 release (tentatively scheduled to release
:in the next 12-18 months), with an eye to completely remove the impacted
:code in a future major release.  The default configuration could be
:overridden to re-enable TLS 1.0/1.1 at build time.
:
:Questions to the community are:
:
:1) Are distributions/users comfortable with this approach in the time frame
:proposed?

Not really.  Entities who control the OpenSSL they run on their
systems, OSes, etc. don't necessarily control all the broken things
that said systems/OSes need to interact with.   

:2) Would builders of OpenSSL consider using the default configuration (with
:TLS1.0/1.1 disabled in 4.0), or would they ship with these protocols
:re-enabled in their builds?

Either it'd be re-enabled in the build, or there'll be a fork that
supports TLS 1.0/1.1 in relative perpetuity.  It was only recently
that some mainstream Linuxes stopped shipping a compat openssl 0.9.8
and all the stale protocol baggage that goes along with that, for
support of some "business critical" commercial apps.  

:3) If the deprecated protocols are re-enabled, what would constitute a
:reasonable warning mechanism to inform users that these protocols are going
:away at some point in the future to pressure users to update to a newer,
:more secure protocol?

I'd be inclined to position such a move and associated warning message
in terms of PQC, which AFAIK doesn't and won't support TLS 1.0/1.1.
As PQC gets "refined", it wouldn't surprise me to see the quantum
computing boogeyman drive out TLS 1.0/1.1 in critical applications.
Let PQC be the spike that kills TLS 1.0/1.1 dead.  

I've been leery to post this for fear of going too far down some
"quantum" rat's nest.  So please, be gentle.


Take FWIW...
-Mike

-- 
 Michael J. O'Connor                                          mjo@...o.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"You can't teach an old dogma new tricks."                    -Dorothy Parker

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.