Re: feedback requested regarding deprecation of TLS 1.0/1.1

[Clemens Lang <cllang () redhat com>]

Hi Neil,

> On 6. Aug 2024, at 11:02, Neil Horman <nhorman () openssl org> wrote:
>
> 1) Are distributions/users comfortable with this approach in the time frame
> proposed?

I don’t think this will be a problem for Fedora, CentOS Stream, and RHEL.
They mostly disable TLS <1.2 without a simple way to bring it back already.


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

I would strongly argue for keeping those disabled in Fedora. It’s already not simple to re-enabled them in CentOS 
Stream or RHEL.


> 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 believe the best you can do as a library is what you are already doing: Disabling by default, and possibly marking 
any TLS-1.0/1.1-specific APIs deprecated.

Logging to stderr from a library is out of the question. Logging to syslog can fail due to SELinux on distros that have 
it.

The only other good solution we’ve come up with is to add a USDT probe point to deprecated code paths and provide a 
utility for users to run on their system that will highlight any use of these code paths. That’s Linux-specific, and 
most users won’t run such a tool, though.


HTH,
Clemens

-- 
Clemens Lang
RHEL Crypto Team
Red Hat