Re: feedback requested regarding deprecation of TLS 1.0/1.1

[Neil Horman <nhorman () openssl org>]

Ack, thank you for the candid feedback, it's helpful

On Tue, Aug 6, 2024, 6:10 PM Alex Gaynor <alex.gaynor () gmail com> wrote:

> Hi Neil,
>
> Answering on behalf of the Python Cryptographic Authority, which
> develops pyca/cryptography, the most widely used Python cryptography
> library. We distribute binary builds that statically link a copy of
> OpenSSL.
>
> 1) Yes, we're fine with dropping TLS 1.0/1.1 on this time frame.
> Frankly, we'd be fine dropping it faster.
>
> 2) We would not re-enable TLS1.0/1.1 in our releases. Users wishing to
> use these protocols would be responsible for building and linking
> their own OpenSSL.
>
> 3) I don't have a good answer for you. I think systems programming is
> fairly impoverished in terms of ways to emit _runtime_ warnings. I'd
> suggest focusing on compile-time warnings.
>
> Alex
>
> On Tue, Aug 6, 2024 at 7:29 AM Neil Horman <nhorman () openssl org> wrote:
> > Neil Horman <nhorman () openssl org>
> > 4:19 AM (42 minutes ago)
> > to openssl-security
> >
> > 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?
> >
> > 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?
> >
> > 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?
> >
> > Input on these questions is requested and appreciated
>
>
>
> --
> All that is necessary for evil to succeed is for good people to do nothing.