RFR: 8328608: Multiple NewSessionTicket support for TLS

John Jiang jjiang at openjdk.org
Wed Jun 19 15:18:13 UTC 2024


On Wed, 5 Jun 2024 17:33:02 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Cache.java line 683:
>> 
>>> 681: 
>>> 682:         // Limit the number of queue entries.
>>> 683:         private static final int MAXQUEUESIZE = 10;
>> 
>> What do you think about making this tunable through the constructor, perhaps with a default value of 10?
>
> I thought about this, but found no reason as this is an internal API.   `QueueCacheEntry<>` is only for TLS client NewSessionTicket situation and the API would have to set that at the time the whole cache is built.  Even with that, it would still be a hard coded number, just somewhere else.  Unless we have yet another system property.  I don’t see a need for individual tuning at this time and we can always up the hardcoded limit if more are needed. If it is necessary in the future we can revisit this.

I have a similar idea as that Jamil thought about.
However, I think the constant `MAXQUEUESIZE` can be moved to class `MemoryCache` as a field.
It may be better to ask the applications to determine the size limit when the cache is instantiated.
Then, all the `QueueCacheEntry`s in a single `MemoryCache` have the same size limit, but different caches can have different limits.

This JSSE feature designs that the server sends 10 or less session tickets, so it's fine that `MAXQUEUESIZE` or the queue size limit is 10, but other (future) features may want different limits.
Although class `sun.security.util.Cache` is an internal utility, it's not JSSE internal.

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

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



More information about the security-dev mailing list