Hi,

Kevin Kofler via devel devel@lists.fedoraproject.org wrote:

If the default crypto policies fail with the world's largest WiFi network, then surely they are too strict to be useful in practice and need to be relaxed.

It may be the world’s largest WiFi network, but authentication is delegated to the various institutions. The TLS server that handles authentication is probably run by this user’s university IT department, and their server does not support modern TLS.

I hope you’re not suggesting we keep the defaults insecure because there are some institutions out there that don’t support modern standards.

Quoting Kevin Kofler via devel (2022-06-30 13:16:55)

Clemens Lang wrote:

...

I hope you’re not suggesting we keep the defaults insecure because there are some institutions out there that don’t support modern standards.

Sorry, but I am. The defaults need to work out there in the real world.

Your model lacks the driver for deprecating anything for good, in neither defaults nor the real world.

If legacy standards are still widespread, they need to be supported out of the box,

Yes.

without having to jump through hoops.

No, or nothing ever moves on, squarely because

Users want to be able to connect to their WPA* WiFi networks, view their HTTPS websites, etc. They do not care whether those use the latest, most secure versions of the standard or not.

Quoting Kevin Kofler via devel (2022-06-30 14:15:04)

You are making two doubtful assumptions:

1. That the users will bother reporting their issues to the server

administrators at all. I would expect them to just blame Fedora for it and move to a different operating system that just works, or at most to apply a local workaround (what I called "jump through hoops", e.g., changing the system crypto policy to LEGACY and/or loading the legacy provider with its legacy algorithms into OpenSSL) and then forget about it.

2. That the server administrators will actually care about complaints from

non-Windows users, assuming they even read user complaints at all to begin with, and that they will be willing to switch to newer (more secure) algorithms that may break compatibility with some ancient operating systems that other users might still use.

I agree with your statements but I do not make the assumptions you prescribe to me. I'm painfully aware that progress doesn't happen magically when we break something in Fedora. Hoops are a horrible propellant of progress, but still the best one we have.

I do not believe that Fedora actually has any levy to get server administrators to upgrade their setups. We have to work with whatever obsolete junk is out there.

Is Fedora supposed to be a locomotive of secure defaults? In an attempt to slow down devolving into opinion-vs-opinion, let me back mine with https://docs.fedoraproject.org/en-US/project:

Four Foundations: First

We are committed to innovation.

We are not content to let others do all the heavy lifting on our behalf; we provide the latest in stable and robust, useful, and powerful free software in our Fedora distribution.

At any point in time, the latest Fedora platform shows the future direction of the operating system as it is experienced by everyone from the home desktop user to the enterprise business customer. Our rapid release cycle is a major enabling factor in our ability to innovate.

We recognize that there is also a place for long-term stability in the Linux ecosystem, and that there are a variety of community-oriented and business-oriented Linux distributions available to serve that need. However, the Fedora Project’s goal of advancing free software dictates that the Fedora Project itself pursue a strategy that preserves the forward momentum of our technical, collateral, and community-building progress. Fedora always aims to provide the future, first.

In terms of cryptographic defaults, Fedora even lags behind RHEL, so requests to slow down even further don't elicit much support from me. If one day this page replaces "First" with, say, "Compatibility: we have to work with whatever obsolete junk is out there, security comes second", I will concede. But today, I think the current pace of deprecations *in the default configuration* doesn't just align with Fedora's goals, it's slower than it should be.

Non-default configurations are a different beast altogether, and the users' feet-shooting freedom is something we should defend, yes. But the defaults have to march on unabated.

V Thu, Jun 30, 2022 at 10:46:27PM +0100, Richard W.M. Jones napsal(a):

Practically what would help is an easier way to reduce security for only specific sites + protocols. It's very easy right now to set the whole system to LEGACY, and much harder to set legacy for a specific site + protocol. (In fact I have no idea how to go about it for this particular case we're talking about.)

Cryptopolicy would work as a soft limit. Cryptolibraries would return a distinct error INSECURE instead of UNKNOWN. Applications on the INSECURE error would offer a user to override the cryptopolicy soft limit.

At the end cryptolibraries many times keep implementing the weak algorithms because the algorithms might be strong enough for a different purpose (like a digest vs. an HMAC), or the cryptopolicy gives a different security level to different purposes (creating vs. verifying a signature), or because the user is not interested in the cryptographical guarantees at all, he only wants to unwrap the wanted data (e.g. reading an ancient digitally-signed message).

For the first and the last case cryptolibraries already provide a mean for applications to convey an intent for, or a use of the algorithm. It's "only" necessary to augment API of the libraries to support the intent parameter everywhere.

Now cryptopeople will argue that users will learn to click "connect anyway" all the time. Well, there will be users like that. But not everbody is like that. I'd rather use a device which I can control than me to be controlled by the device.

-- Petr