On Tue, 24 Mar 2026 08:48:09 GMT, Hai-May Chao <[email protected]> wrote:
>> src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 1: >> >>> 1: /* >> >> This logic is specific to the current Hybrid KEM draft. Is there a chance a >> different (e.g. non-hybrid) KEM might have different behavior specified? >> >> (I don't know the answer, but wanted to check.) > > The IETF spec (for non-hybrid): ML-KEM Post-Quantum Key Agreement for TLS > 1.3, defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024. > > https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > > In section 4.2, it specifies that: > > For all parameter sets, the server MUST perform the encapsulation key > check described in Section 7.2 of [FIPS203] on the client's > encapsulation key, and abort with an illegal_parameter alert if it > fails. > > For all parameter sets, the client MUST check if the ciphertext > length matches the selected parameter set, and abort with an > illegal_parameter alert if it fails. > > If ML-KEM decapsulation fails for any other reason, the connection > MUST be aborted with an internal_error alert. > > So ML-KEM (non-hybrid) has the same behavior requirements as hybrid > ECDHE-MLKEM, and the exceptions mapping to TLS alerts covers both. The > difference is that ECDH validation is only applicable to hybrid ECDHE-MLKEM. My concern is that come future different KEM algorithm (e.g. KEMTLS/IND-CCA(2)/RSA-KEM/other lattice-based alternatives) might have different required TLS behavior. (This is for down the road, I guess). Since it's not an API here, I guess we will cross that bridge when we come to it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30039#discussion_r2985426037
