On Sat, 6 Dec 2025 17:20:16 GMT, Hai-May Chao <[email protected]> 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
