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