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

[Bradford Wetmore]

On Sat, 6 Dec 2025 17:20:16 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/DHasKEM.java line 91:
>> 
>>> 89:             // The order of shares in the concatenation for group name
>>> 90:             // X25519MLKEM768 has been reversed. This is due to IETF
>>> 91:             // historical reasons.
>> 
>> Can we just change this to something like "as per the current draft RFC?"  
>> 
>> "historical reasons" is too vague.  The draft is the real reason.
>
> Updated comment as suggested (comment is in HybridProvider class now).

Be sure to open a bug to update the mentions of the draft to RFC when they go final.

>> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 635:
>> 
>>> 633: 
>>> 634:             if (handshakeSecret == null) {
>>> 635:                 SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
>> 
>> Since we only end up with one possession, can we move this up into the for loop?  Each of the various possession types goes through the `for` loop, so seems this would be a tiny bit clearer.
>> 
>>     for () {
>>         if (pos instanceof ...) {
>>             handshakeSecret =...
>>         } else {
>>             SSLKeyDerivation handshakeKD = ...
>>         }
>>     }
>
> Keep the code as it is. This is because if we move the KA derivation code to the for loop as the else branch, we make it appear to be associated with a possession. KA does not store the shared secret in a possession like KEM, so keep its logic separate.

Ok, I can see that.

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

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