RFR: 8367059: DTLS: loss of NewSessionTicket message results in handshake failure [v7]

[Jamil Nimeh]

On Mon, 13 Oct 2025 17:28:06 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> If the NewSessionTicket message is lost, the handshake fails on the client side with:
>> javax.net.ssl.SSLHandshakeException: (decrypt_error) The Finished message cannot be verified.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore "createSSLEngine" access privileges to make existing tests pass

src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java line 1631:

> 1629:                     && (!tc.sslConfig.isClientMode
> 1630:                     || !tc.handshakeContext.statelessResumption
> 1631:                     || hasCompleted(SSLHandshake.NEW_SESSION_TICKET.id));

Stylistically this is a bit weird putting the comment mid-stream into a complex logical comparison.  I get why you're doing it here, but I think it will be easier to read things if the comment goes above the return statement.

src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java line 551:

> 549:                 if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
> 550:                     SSLLogger.info(
> 551:                             "Server doesn't support stateless resumption");

Would it be more accurate to indicate that the client is disabling stateless resumption due to the missing message?  Because, up to that point, the assumption is that the server does support this kind of resumption and now it's being turned off.
I'm curious, does this get run and the stateless resumption disabled if this scenario occurs:

- server receives client finish and verifies successfully
- server sends NST, but it goes AWOL
- server sends CCS
- server resends the lost NST
- server sends finish

Not sure if that scenario can happen since the CCS moves us onto the next epoch, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471640638
PR Review Comment: https://git.openjdk.org/jdk/pull/27677#discussion_r2471652428