RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v6]

[Sean Mullan]

On Thu, 30 Oct 2025 16:18:11 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> It might depend on which level we're disabling things at.  If we're talking about knocking out x25519 in the namedGroups property then no, it won't disable the hybrid.  The client will just choose a different key share to use with X25519MLKEM768 in the initial client hello.  I know I've tried knocking out x25519 as a disabled algorithm in the past and I believe it will knock out the hybrid as well since the lower-level KeyAgreement operation in the DH provider that the hybrid uses should be blocked.  I can test that again to make sure my memory is correct on that point.
>
> Update: I was only half-right.  Via the `jdk.tls.namedGroups` property or SSLParameters, each named group stands on its own.  You can add or remove them without impacting the others.  When I took `x25519` out, it sent `X25519MLKEM768` and `secp256r1` key shares in the initial client hello.
> 
> Adding `x25519` to java.security (`jdk.tls.disabledAlgorithms`) does not prevent a hybrid with that component from functioning.  I just tested that a few moments ago.  I went back through some notes from a few months ago and I had that behavior documented there as well.
> 
> That seems consistent with what we say in the JEP about hybrid schemes: "... and is secure as long as one of the algorithms remains unbroken."

Good, the latter behavior was what I was questioning and I agree that is the way it should work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2478759010