JDK-8148516 : Increase the minimum strength of EC keys
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 6,7,8,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-01-28
  • Updated: 2018-05-09
  • Resolved: 2016-07-09
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 8 JDK 9 Other
8u152Fixed 9 b127Fixed openjdk7uFixed
Related Reports
Relates :  
JDK-8161232 - AsyncSSLSocketClose.java test fails timeout.
Relates :  
JDK-8177071 - typo in test DisabledAlgorithms.java
Relates :  
JDK-8176479 - javax.net.ssl.SSLHandshakeException: Unsupported curveId: 21
Relates :  
JDK-8173783 - IllegalArgumentException: jdk.tls.namedGroups
Relates :  
JDK-8167472 - Chrome interop regression with JDK-8148516
Relates :  
JDK-8166362 - [TEST_BUG] test sun/net/www/http/HttpClient/B8025710.java failing with cert error in 8u121 b01
Sub Tasks
JDK-8148912 :  
Release Note: Improve the default strength of EC in JDK. - Closed
JDK-8174227 :  
Release Note: IllegalArgumentException from TLS handshake - Closed
Description
Per NIST SP 800-57, EC curves less than 224 should be disallowed since 2013, and curves less than 256 should be disallowed since 2030. 

As EC usage in TLS is relative new, almost all TLS implementations default to the NIST P-256 or stronger curves.  Disable curves less than 256 bits should cause no issues.
Comments
8u121 release notes : http://www.oracle.com/technetwork/java/javase/8u121-relnotes-3315208.html Note that the 224 bit limit can be modified via java.security file modification. The 256 bit limit for the default enabled list in JDK TLS provider is hardcoded. A specific list of curves can be used by setting the new system property : jdk.tls.namedGroups. Note that weak curves should not be specified. Best approach is to modify the application if exceptions like the following are seen : "javax.net.ssl.SSLHandshakeException: Unsupported curveId: 21" For reference, I've pasted the EC curve names here along with their corresponding JDK ids ECDSA Keysize : (id in brackets) 160-223 : sect163k1(1), secp163r2(3), secp193r1(4) 224-255 : secp224r1(21), sect233k1(6), sect233r1(7) 256-383 : secp256r1(23), sect283k1(9), sect283r1(10) 384-511 : secp384r1(24), sect409k1(11), sect409r1(12) 512+ : secp521r1(25), sect571k1(13), sect571r1(14)
16-02-2017
FC Extension Request: This update is approved and ready to integrate. If this FC extension request get approved, we can integrate the fix shortly after. In a talk at the 32th Chaos Communication Congress (32C3), Nick Sullivan from CloudFlare mentioned a new potential attack against the TLS handshake called CurveSwap. At the moment this attack is only theoretical, however, all TLS implementations that we know of default to the NIST P-256 or stronger curves, so it seems reasonable to remove support for potentially weak curves from TLS implementations as a precaution. This update restricts EC keys less than 224 bits in certification path processing and SSL/TLS/DTLS connections, and remove curves weaker than 256 bits from the default enabled list in JDK SSL/TLS provider. The risk should be minimal as almost all TLS implementations default to the NIST P-256 or stronger curves. In case of compatibility issue, a system property is added to customize the enabled curves. The Fix can be pushed within 1-2 days of approval since it is already implemented and reviewed.
06-07-2016