8373426: Remove ffdhe6144 and ffdhe8192 from default list of TLS named groups

[kirill-shirokov]

Removed FFDHE_6144 and FFHDE_8192 from the default list of TLS named groups, so now to consider them as candidates in TLS handshake user has to enable them explicitly (e.g. -Djdk.tls.namedGroups=ffdhe6144,ffhde8192)

Tested on Linux x64/aarch64, MacOS aarch64, Windows x64 using jtreg test/jdk/sun/security/ssl and test/jdk/javax/net/ssl.

tests-linux-aarch64.log
tests-linux-x86.log
tests-macos-aarch64.log
tests-windows-x64.log

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change requires CSR request JDK-8377197 to be approved
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issues

• JDK-8373426: Remove ffdhe6144 and ffdhe8192 from default list of TLS named groups (Enhancement - P4)
• JDK-8377197: Remove ffdhe6144 and ffdhe8192 from default list of TLS named groups (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/29577/head:pull/29577
$ git checkout pull/29577

Update a local copy of the PR:
$ git checkout pull/29577
$ git pull https://git.openjdk.org/jdk.git pull/29577/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 29577

View PR using the GUI difftool:
$ git pr show -t 29577

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/29577.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back kshiroko! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@kirill-shirokov The following label will be automatically applied to this pull request:

• security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (8930f189)
• 00: Full (86ff15b8)

[seanjmullan]

/csr

[seanjmullan]

This will require a CSR, since it is a change to default behavior. The compatibility risk should be very low, since these named groups should rarely be used in practice.

[openjdk]

@seanjmullan has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@kirill-shirokov please create a CSR request for issue JDK-8373426 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[XueleiFan]

any bad to keep them? I did not get the idea to take the compatibility risks.

[seanjmullan]

any bad to keep them? I did not get the idea to take the compatibility risks.

Why are they needed by default? AFAIK nobody ever uses them and other groups will always be negotiated before them since they are at the end of the list. No other TLS impl that we know of includes these groups by default.

[XueleiFan]

Compatibility risks is the reason to keep it.

…

On Wed, Feb 4, 2026 at 1:36 PM Sean Mullan ***@***.***> wrote: *seanjmullan* left a comment (openjdk/jdk#29577) <#29577 (comment)> any bad to keep them? I did not get the idea to take the compatibility risks. Why are they needed by default? AFAIK nobody ever uses them and other groups will always be negotiated before them since they are at the end of the list. No other TLS impl that we know of includes these groups by default. — Reply to this email directly, view it on GitHub <#29577 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSB3EFEPP6G7YPENUNFJBT4KJQ5LAVCNFSM6AAAAACT73MYXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNBZHA3DGMJVG4> . You are receiving this because you commented.Message ID: ***@***.***>

[XueleiFan]

Vendor default is different from application uses. Once there is an application depends on the behavior, there is compatibility risks. Why take the risks? There should be a good reason as it has potential compatibility risks.

…

On Wed, Feb 4, 2026 at 2:55 PM Xuelei Fan ***@***.***> wrote: Compatibility risks is the reason to keep it. On Wed, Feb 4, 2026 at 1:36 PM Sean Mullan ***@***.***> wrote: > *seanjmullan* left a comment (openjdk/jdk#29577) > <#29577 (comment)> > > any bad to keep them? I did not get the idea to take the compatibility > risks. > > Why are they needed by default? AFAIK nobody ever uses them and other > groups will always be negotiated before them since they are at the end of > the list. No other TLS impl that we know of includes these groups by > default. > > — > Reply to this email directly, view it on GitHub > <#29577 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AQSB3EFEPP6G7YPENUNFJBT4KJQ5LAVCNFSM6AAAAACT73MYXCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNBZHA3DGMJVG4> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[XueleiFan]

other groups will always be negotiated before them since they are at the end of the list.

I don't think we can come to this conclusion. Per TLS specification, at the end of the list, does not mean it will not be used. That's the reason why the specification is defined so. Otherwise, just one entry is fine.

[kirill-shirokov]

CSR: https://bugs.openjdk.org/browse/JDK-8377197
Created it to the best of my/AI knowledge. Please feel free to comment/fix it.

[myankelev]

Could you please add an ID to @bug?

[kirill-shirokov]

Done.

[seanjmullan]

other groups will always be negotiated before them since they are at the end of the list.

I don't think we can come to this conclusion. Per TLS specification, at the end of the list, does not mean it will not be used. That's the reason why the specification is defined so. Otherwise, just one entry is fine.

These extremely large groups should really be opt-in as they are almost never used in practice and require additional resources to process, so the server should opt-in. I have found no evidence of them being used anywhere - do you have any references? In general, DHE groups and cipher suites are becoming legacy and I expect the JDK to eventually deprecate more of them as we move forward in the next few years.

The CSR's purpose is to document compatibility risk.

[jnimeh]

I agree with Sean. I can't think of a case where these larger DHE exchanges are used. When we did hybrid named groups, we looked at what many browsers and libraries did. While browsers like Mozilla and libraries like OpenSSL still have FFDHE named groups, they all use ffdhe2048 and ffdhe3072, nothing larger. We'd leave ffdhe4096 for the more stringent security cases, but anything beyond that is just not seen out there AFAICT. And we're just talking about the default case here - in some particularly security-sensitive case users can still enable these via property or API calls (putting aside the question of why something that security sensitive would want DHE at all when hybrid named groups are available and larger EC solutions like secp521r1 and x448).

[XueleiFan]

I have found no evidence of them being used anywhere - do you have any references?

No, I don't. There are lot of project are internal and private. It is hardly to know every deployment in practice. If you are confident that no one actually use it in practice, it is surely safe to remove and no compatibility issues. So if you are confident, please go ahead. Otherwise, I did not see bad impact to keep them at this moment.

in some particularly security-sensitive case users can still enable these via property or API calls

It is not easy to update source code in practice, especially for third party's dependencies. For property, service may fail firstly, and then know to set the property. No one really know every line of code of a product or service. I did not see the reason to get the trouble yet.

DHE groups and cipher suites are becoming legacy

That's a good reason to deprecate DHE groups and cipher suites, but not for removing current groups like that.

Anyway, I did not see the benefit to remove them, and would not like to take risks that I don't understand. But I don't mind if you are confident.