RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider

[Valerie Peng]

On Mon, 29 Sep 2025 16:54:41 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Change SunJSSE to use `TlsUpdateNplus1` instead of `AES` as the key algorithm when deriving the next application traffic secret.
>> 
>> SunPKCS11 provider checks the key length when creating an `AES` key, and since 384 bits is not a valid AES key length, the key creation fails.
>> 
>> `TlsUpdateNplus1` is [already recognized](https://github.com/openjdk/jdk/blob/3c9fd7688f4d73067db9b128c329ca7603a60578/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L287) as a standard TLS generic key by SunPKCS11.
>> 
>> Key update is now exercised by the FipsModeTLS test. The test passes with the changes, fails without them. Other tier1-3 tests continue to pass.
>
> src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 215:
> 
>> 213:             if (this == TlsKey)
>> 214:                 return cs.bulkCipher.algorithm;
>> 215:             return algorithm;
> 
> nit: how about just `return (this == TlsKey ? cs.bulkCipher.algorithm : algorithm);`

In addition, looking at the KeySchedule enum, only `TlsIv` is of iv type, so overall we don't really need the `isIv` field. If we change the `getKeyLength(CipherSuite cs)` method as below, then we can remove the `isIv` field.

+            return switch (this) {
+                case TlsUpdateNplus1->cs.hashAlg.hashLength;
+                case TlsIv->cs.bulkCipher.ivSize;
+                case TlsKey->cs.bulkCipher.keySize;
+                default->throw new RuntimeException("Unexpected exception");
+            };

What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27498#discussion_r2388638214