My understanding is that this change will result in Firefox, the default browser in Fedora Workstation, refusing to load webpages that will continue to be accepted by upstream Firefox (CC @stransky).

Mozilla telemetry suggests that TLS 1.1 use on the web is negligible, but TLS 1.0 is still used. Disabling TLS 1.0 and 1.1 will break 1.12% (TLS 1.0) + 0.11% (TLS 1.1) = 1.23% of TLS connection attempts, or 1.46% + 0.01% = 1.47% if we restrict the telemetry to just Linux users: https://mzl.la/2JKcfiZ. (I think I'm reading that right.)

I was unable to find any telemetry to indicate how many connections will break if the required finite field parameter size is increased. I have absolutely no clue what the impact of this will be. I'd ask that the change proposal should include some investigation and numbers, which might be difficult to acquire.

Note the number of broken webpages will be much higher than the number of broken connections, because the most-visited websites tend to have the strongest security settings. E.g. if, hypothetically, 95% of total TLS connections are made to Google, Facebook, Netflix, and Reddit, then the entire rest of the web would obviously be represented as only 5% of the total TLS connections.

My proposal would be to reject the crypto policy changes until upstream Firefox first makes the same choice. Since the system crypto policy applies to all applications in Fedora, the policy must be set appropriately for web browsers. Accordingly, it should probably match whatever Mozilla is doing. My expectation is that upstream Firefox will probably not consider this change until either (a) a major vulnerability is discovered, more severe than those currently-known, or (b) usage of TLS 1.0 drops by approximately one order of magnitude below its current level.

I was unable to find any telemetry to indicate how many connections will break if the required finite field parameter size is increased. I have absolutely no clue what the impact of this will be. I'd ask that the change proposal should include some investigation and numbers, which might be difficult to acquire.

BTW: lacking any evidence, my intuition is that increasing the parameter size would be a bad idea. This has been a compatibility issue for me in the past, back when major browsers accepted very small parameter sizes (much lower than 1024 bits) but GNOME did not. It's why GnuTLS now orders DH ciphersuites last in the handshake, to avoid them getting selected at all unless absolutely necessary.

(Of course, the proposed changes would undoubtedly be good for security. But my preference is that browsers decide that first. If major browsers increase the parameter size and drop support for TLS 1.2, then websites will fix themselves. If only Fedora does so, then the websites will be broken only in Fedora, likely indefinitely until browsers decide to make the leap.)

BTW: lacking any evidence, my intuition is that increasing the parameter size would be a bad idea. This has been a compatibility issue for me in the past, back when major browsers accepted very small parameter sizes (much lower than 1024 bits) but GNOME did not. It's why GnuTLS now orders DH ciphersuites last in the handshake, to avoid them getting selected at all unless absolutely necessary.

Well, I should have done a bit more investigation: that's a non-issue because it seems both Firefox and Chrome disable DH ciphersuites with TLS 1.2. The web is improving!

This is on the agenda for Friday's FESCo meeting at 15:00UTC in #fedora-meeting on irc.freenode.net, but note that we may not get to it as there is a large agenda and this is the 6th item in line.

AGREED: Let's defer the change until major browsers make the move first, and then propose it as a change for the next release (+7, 1, -0)