On Wed, 4 Feb 2026 19:29:02 GMT, Kirill Shirokov <[email protected]> wrote:
> 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](https://github.com/user-attachments/files/25080233/tests-linux-aarch64.log) > [tests-linux-x86.log](https://github.com/user-attachments/files/25080235/tests-linux-x86.log) > [tests-macos-aarch64.log](https://github.com/user-attachments/files/25080236/tests-macos-aarch64.log) > [tests-windows-x64.log](https://github.com/user-attachments/files/25080237/tests-windows-x64.log) 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). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29577#issuecomment-3855577496
