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