RFR: CSR for 8211018 Session Resumption without Server-Side State
Anthony Scarpino
anthony.scarpino at oracle.com
Thu May 23 18:45:17 UTC 2019
On 5/23/19 11:16 AM, Sean Mullan wrote:
> On 5/21/19 7:24 PM, Anthony Scarpino wrote:
>> Hi All,
>>
>> Please review the CSR for the stateless Server Side
>> https://bugs.openjdk.java.net/browse/JDK-8223922
>
> Some initial comments/questions:
>
> I think the scope should be "JDK" since you are adding new JDK-specific
> system properties that users can set to change the behavior.
Sure
>
> For previous system properties that enable extensions, we have used a
> boolean property with the naming convention
> "jdk.tls.client.enable<ExtensionName" (for example
> "jdk.tls.client.enableStatusRequestExtension", so we should probably
> stick to that convention and call it
> "jdk.tls.client.enableSessionTicketExtension" (with value true/false).
In those other cases with "enable<ExtName>" are they never on by
default. I don't have a problem with renaming it for consistency. But,
when the property is enabled by default, it seems a bit funny
wording-wise to have to use "j.t.c.enableSessionTicketExtension=false"
>
> I was wondering if you really need the jdk.tls.server.sessionCacheState
> system property and if so, why the default is not "mixed". Shouldn't the
> server decide to cache or not depending on whether the client sends the
> SessionTicket Extension?
>
> Thanks,
> Sean
More information about the security-dev
mailing list