Re: feedback requested regarding deprecation of TLS 1.0/1.1

[Pat Gunn <pgunn01 () gmail com>]

OpenSSL is an important and security-critical piece of software; it's
important that it be maintainable, analysable for security properties, and
that at runtime people don't have to worry about weird old code paths
leading to breaches or instability.

Keeping these old code paths around (and particularly enabled) in "relative
perpetuity" is bad for OpenSSL and bad for its users because it prioritises
the long tail (that presumably see very little legitimate use nowadays)
over the main use; there needs to be some kind of cut-off and acceptance
that even if a few historical relics are cut off, it's better for the
mainstream. There are other things that will make those legacies harder to
use anyhow - cert chains, IPv6, potentially physical connectivity. Given
the weights of the interests involved, it's not that hard to peel the relic
cases from the it-works-automatically status into the
you-may-need-to-take-extra-steps status.

The Linux kernel removes support for old architectures for similar reasons.

If someone were to argue a metric apart from relative perpituity, that'd be
different, but I think any reasonable metrics of that flavour would have
lines that have already been crossed in terms of usage numbers or any other
measurable.


On Wed, 14 Aug 2024 at 07:37, Mike O'Connor <mjo () dojo mi org> wrote:

> :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 () dojo mi org
>
>  =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
> "You can't teach an old dogma new tricks."                    -Dorothy
> Parker