On Wed, 29 May 2024 18:53:55 GMT, Anthony Scarpino <ascarp...@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.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 202:

> 200:         Integer nstServerCount = GetIntegerAction.privilegedGetProperty(
> 201:             "jdk.tls.server.newSessionTicketCount");
> 202:         if (nstServerCount == null || nstServerCount < 1 ||

Please permit zero here. It is useful for preventing the connection reset on 
connections where the client is only writing and never reading from the socket.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19465#discussion_r1639413864

Reply via email to