JDK-8233228 : Disable weak named curves by default in TLS, CertPath, and Signed JAR
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7,8,11,14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-10-30
  • Updated: 2021-03-11
  • Resolved: 2019-12-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 15 JDK 7 JDK 8 Other
11.0.9-oracleFixed 13-poolResolved 14 b29Fixed 15Fixed 7u281Fixed 8u270Fixed openjdk7uFixed
Related Reports
CSR :  
JDK-8235540 - Disable weak named curves by default in TLS, CertPath, and Signed JAR
Relates :  
JDK-8226374 - Restrict TLS signature schemes and named groups
Relates :  
JDK-8246330 - Add TLS Tests for Legacy ECDSA curves
Relates :  
JDK-8233227 - Update TLS disabledAlgorithms curve syntax
Relates :  
JDK-8248745 - Add jarsigner and keytool tests for restricted algorithms
Sub Tasks
JDK-8236730 :  
Release Note: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default - Closed
Description
There is a need to disable crypto operations by named curves to the disabledAlgorithms property. This requires deeper checks into the EC classes than previously supported. With over 50 named curves available, adding individual named curves to each disabledAlgorithms properties is a messy situation and needs a cleaner solution.

Adding support to the named curves is straight forward to implement; however, with many named curves, the disabledAlgorithm properties will overwhelm with named curves. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all the disabledAlgorithm properties. To use the new property in the disabledAlgorithm properties, the full property name is used as an entry. Users can still add individual named curves to disabledAlgorithms properties separate from this new property..
Comments
Fix request (7u) https://mail.openjdk.java.net/pipermail/jdk7u-dev/2021-March/011097.html
11-03-2021
OpenJDK 8u review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013287.html
11-01-2021
Fix request (8u) https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013160.html
01-12-2020
Fix request (13u) https://github.com/openjdk/jdk13u-dev/pull/32 There is a merge conflict because JDK-8244479 has been already pushed to the jdk13u repo, but the conflict resolving does not change the code of the original fix.
27-11-2020
OK, after you have it finalized (I've assigned it to you. Even twice:-), Joe D. will approve it, then I'll stamp this issue, and (provided Sergey has his OCA verified) it will be OK to integrate. NB: it should be explicitly "finalized", i.e. status changed to Finalized, for approval process to start
27-11-2020
Hi Alexandr, there's a problem with this fix: 13 is not in that above mentioned "fixed versions" list, so I'm afraid we need to make CSR. To clone CSR most probably. If you know the routine, fine: otherwise take a look at e.g. JDK-8248000 (History tab there) and https://wiki.openjdk.java.net/display/csr -- an unusual step here is manual creation of an empty backport targeted to 13-pool
26-11-2020
I have created a backport issue JDK-8257160 for 13-pool target and CSR JDK-8257161
26-11-2020
Yes, there seems to be a difference between Oracle engeneers and other contributors. We are often forced to do CSRs for downports, while I see lots of downports to 11.0.x-oracle without. If just adding more fix versions to an existing CSR is sufficient that would save a lot of time. Anthony, you might have missed the downport CSRs, as they must be attached to the downport JBS issue, not to the original bug. I think this particular issue is quite important, so I don't want to stretch the process here and I'll do the CSR as for all previous issues. After all, it's just a few clicks to do it. Severing, thanks for pointing me to it.
05-06-2020
Following Tony's hint I checked the original CSR. It was filed and processed for all releases mentioned in its "fixed versions" field, including 11-pool. I never saw such a multi-release CSR so far but given that [~darcy] has approved it, I suppose this satisfies the process. So I'm approving the 11u backport and suggest to close the new backport CSR as duplicate of the original one.
05-06-2020
The CSR applies to the releases listed in the CSR's "Fix Version/s". I've never seen a separate CSR per release.
04-06-2020
The original change required a CSR. In general, we require a CSR for the backport as well before we can approve this. Yet, I don't see a separate CSR specific for JDK 11. I wonder what Oracle did for their backport. Re-used the JDK 14 CSR? I'd like this to be clarified before approval.
04-06-2020
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.9-oracle. Applies clean but keytool/Main.java does not compile. http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003219.html It calls fullDisplayAlgName() to print the warning which is not in 11. I included this rather simple function. This results in the same printout as in jdk15 and makes sure later changes (8172404) downport clean.
02-06-2020
URL: https://hg.openjdk.java.net/jdk/jdk14/rev/169e9680821c User: ascarpino Date: 2019-12-18 20:10:46 +0000
18-12-2019
Late enhancement request approved by Project Lead.
13-12-2019
Late Enhancement Request This feature is needed to remove risks of using weakly implemented named elliptic curves during TLS, certificate chain validation, and signed JAR verification. The feature adds deeper checks into the EC classes than previously supported and cannot currently be done without this change The risk level of this change is minimal as users can change the security properties to re-enable all or some of the curves. The risk level to the release is minimal as it's very localized to the security APIs. This change can be pushed once the CSR is approved. Code reviews are complete.
12-12-2019
It is probably still desirable to do this in 14, so we don't have two different ways to disable curves in certificates in TLS, and there would be less code to maintain and test. For example, right now we use jdk.certpath.disabledAlgorithms to disable MD5 certificates, and this applies to all components that validates certificates, such as TLS.
06-11-2019