RFR: 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider [v2]

Mikhail Yankelevich myankelevich at openjdk.org
Wed Oct 1 13:52:24 UTC 2025


On Tue, 30 Sep 2025 08:14:13 GMT, Daniel Jeliński <djelinski 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.
>
> Daniel Jeliński has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove isIv
>  - Replace if/else with ternary

src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java line 204:

> 202:         int getKeyLength(CipherSuite cs) {
> 203:             return switch (this) {
> 204:                 case TlsUpdateNplus1 -> cs.hashAlg.hashLength;

I believe this is not covered by any tests, do you think the test could be amended to cover this case?

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

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


More information about the security-dev mailing list