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

[Artur Barashev]

On Wed, 29 Oct 2025 03:51:13 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

>> 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/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?

- Do you mean to use a different log message? The stateless session resumption is enabled by default, so if server doesn't send "session_ticket" extension we disable it on the client side. 
- We support DTLSv1.2 only and in v1.2 NST must come before CCS and finished, so verifying Finished would fail if NST goes missing (server and client would have different handshake hashes) - that's exactly what happens in this ticket we are fixing. And yes, CCS would set a new epoch.

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

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