RFR: 8328608: Multiple NewSessionTicket support for TLS

[John Jiang]

On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi
> 
> This change is to improve TLS 1.3 session resumption by allowing a TLS server to send more than one resumption ticket per connection and clients to store more.  Resumption is a quick way to use an existing TLS session to establish another session by avoiding the long TLS full handshake process.  In TLS 1.2 and below, clients can repeatedly resume a session by using the session ID from an established connection.  In TLS 1.3, a one-time "resumption ticket" is sent by the server after the TLS connection has been established.  The server may send multiple resumption tickets to help clients that rapidly resume connections.  If the client does not have another resumption ticket, it must go through the full TLS handshake again.  The current implementation in JDK 23 and below, only sends and store one resumption ticket.
> 
> The number of resumption tickets a server can send should be configurable by the application developer or administrator. [RFC 8446](https://www.rfc-editor.org/rfc/rfc8446) does not specify a default value.  A system property called `jdk.tls.server.newSessionTicketCount` allows the user to change the number of resumption tickets sent by the server.  If this property is not set or given an invalid value, the default value of 3 is used. Further details are in the CSR.
> 
> A large portion of the changeset is on the client side by changing the caching system used by TLS.  It creates a new `CacheEntry<>` type called `QueueCacheEntry<>` that will store multiple values for a Map entry.

> The application calls `getSession()` from the same SSLContext of the original connection.
> ...
> The remaining tickets sit on the client if they need them. Some applications may choose to resume multiple times to download data/images.

I might miss something.
The client can connect to the server in parallel, and these new connections can share the SSLContext from a previous connection.
And the new connections automatically pick the cached sessions in that SSLContext one by one.
Right?

> These cached entries are not for public API usage. They are just for resumption of existing sessions. This is no different than it is today where a TLS v1.3 stateless ticket or PSK cannot be accessed by the public API. Creating a public API would be a big change given there is no public object to identify a cached entry and no way to start a new session from a cached entry. A public API is not in the scope of this change.

I did understand that and did not call for new public APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2182243938