In our current implementation of QUIC, in the TLS layer, when the server is producing a TLS Finished message during the handshake, we also derive the 1-RTT keys for the server. This generates both the write keys (for encrypting packets to be sent by the server in 1-RTT packet space) and the read keys (for decrypting packets received by the server in 1-RTT packet space).

The TLS Finished message is expected to signal the completion of the TLS handshake and each endpoint is expected to send the Finished message. RFC-9001 states that until the TLS handshake is complete, the incoming 1-RTT packets should not be decrypted, even if the 1-RTT keys are available by then. Our current implementation of QUIC does indeed follow this specification and doesn't decrypt such 1-RTT packets until the TLS handshake is complete.

As an additional feature, for the server side, it would be good to even delay the derivation of the 1-RTT read keys until after the TLS handshake is complete (i.e. until after the client has sent the TLS Finished message and the server has processed and verified it).

While at it, we should also consider optimizing the current implementation in T13FinishedProducer.onProduceFinished(ServerHandshakeContext shc, HandshakeMessage message) method. We should consider skipping the calculation of the SSL WriteCipher when QUIC is in use. Also, we're calculating the baseWriteSecret twice (deriveOneRTTKeys calculates the same secret). That could be improved too. The same improvements can be applied to T13ServerHelloProducer where we calculate handshake keys, and to the corresponding consumers.

For additional context see the PR review comment here https://github.com/openjdk/jdk/pull/24751#pullrequestreview-2963022948