This is the proposed step 1 of the plan.

Add "tlsv1" and "tlsv1.1" to the jdk.tls.legacyAlgorithms security property.  This restriction depends on support for the "supported_versions" extension. This extension is currently supported in JDK 10 for TLS 1.2, and in JDK 11 it is supported for TLS 1.0, 1.1, 1.2, and 1.3. Backporting this to earlier JDKs would be a moderate effort (rough estimate of 4 engineering weeks).

A TLS client lists the versions it supports in the supported_versions extension in preference order. A TLS server selects one that it also supports from the list. For security reasons, the JDK TLS server implementation doesn't necessarily use the client's preferred order, instead it bases it selection on its own preferred order.

By default (i.e. no configuration changes) a Java client and server order the versions in the most secure order: "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1".

Thus, adding TLS 1.1 and 1.0 to the jdk.tls.legacyAlgorithms property only has a benefit under the following circumstances:

1. A JDK TLS server's enabled protocols have been explicitly configured (using the setEnabledProtocols API or jdk.tls.server.cipherSuites system property) to use a different order, either intentionally or accidentally such that a weaker protocol (1.1 or 1.0) is preferred. In this case, the weaker protocols would be moved to the end of the list.

2. A JDK TLS client's enabled protocols have been explicitly configured (using the setEnabledProtocols API or jdk.tls.client.cipherSuites system property) to use a different order, either intentionally or accidentally such that a weaker protocol (1.1 or 1.0) is preferred. A non-JDK TLS Server implementation may respect the client's order and choose the weaker protocol (it is not known if any other TLS implementations do that, however). Thus, we could reorder the protocols such that TLS 1.1 and 1.0 is last.