JDK-8227530 : Session Resumption without Server-Side State off by default
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2019-07-10
  • Updated: 2020-07-22
  • Resolved: 2019-07-16
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Description
Summary
-------

Change the default system properties for Session Resumption without Server-Side State to false.  This sets it off by default.

Problem
-------

Concerns over SSLSession API consistency for sessions that the server no longer stores.  Because the stateless resumption keeps no state some of the methods of getting information about the session are no longer available.  For example SSLSession.invalidate() has no mechanism to invalidate the session from resumption because there is no state kept on the server.  It was initially decided that this was ok, but recently decided that the server needs a mechanism to know to invalidate the session.  Additionally the RFCs state TLS session IDs can be different for resuming sessions in a stateless environment.  The SSLSession.getId() returns a session identifier.  There is disagreement if this method should be returning a session identifier that is consistent across resumed session that have a different TLS session ID, or if it should return the TLS session ID.  The method's API doc is ambiguous.  Some time soaking in 14 may help give us that answer.  Some of the context that is in SSLContext does not have the same level of data, such as getting all the session id's in the servers side cache that is now blank in stateless mode.  In this situation, we are unlikely to provide any extra data, but some time as an opt-in option and soak time in 14 would be good feedback.

Solution
--------

Set default value for properties to false.  it's better to resolve some of these issues with the stateless disabled and give users a release to test our their products as jdk14 this will be enabled by default.

Specification
-------------

    +++ b/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java	Wed Jul 10 07:38:22 2019 -0700
    @@ -234,13 +234,13 @@
             // Property for Session Cache state
             if (server) {
                 st = GetPropertyAction.privilegedGetProperty(
    -                        "jdk.tls.server.enableSessionTicketExtension", "true");
    +                        "jdk.tls.server.enableSessionTicketExtension", "false");
                 } else {
                     st = GetPropertyAction.privilegedGetProperty(
    -                        "jdk.tls.client.enableSessionTicketExtension", "true");
    +                        "jdk.tls.client.enableSessionTicketExtension", "false");

Comments
Moving to Approved.
16-07-2019

Please update the "Problem" section with a brief discussion of the background and motivation for the change and Finalize the request.
15-07-2019

Yes, the change is only for 13 because the release end is too close to address some inconsistencies between stateless and stateful. There is discussion because the nature of stateless presents questions for an API built around a stateful implementation. The release note change will be simple as the original release note for JDK 8211018 will now say "not enabled by default", and "false (default). There was no plan to spell out the inconsistencies in the release notes as there is still ongoing discussion.
11-07-2019

Okay, so you want to change the default of an introduced-in-13 system property? Is the documentation of this change going to be subsumed into the documentation of the system property in the release notes?
11-07-2019

I'm not sure exactly which context your looking for. Here are the original rfe and csr that this relates to: JDK-8211018 & JDK-8223922
10-07-2019

I'm advancing this request to Provisoinal, but I'll need at least a pointer to some additional context before I'll be able to evaluate a Finalized form of this request.
10-07-2019