RFR 8211018: Session Resumption without Server-Side State

[Xuelei Fan]

On 6/4/2019 9:46 AM, Anthony Scarpino wrote:
>> 125             if (secondSession.getCreationTime() > secondStartTime &&
>> 126                     !clientCache && !serverServerless) {
>> 127                 throw new RuntimeException("Session was not reused");
>> 128             }
>> If the session should be resumed via session ID, beside checking the 
>> creation time, would it be better to compare the session IDs for 
>> double-checking?
> 
> the client side in stateless mode sends no session id, as the spec 
> allows.  So the session id has no more value.
I think it is a legacy problem introduced in the TLS 1.3 implementation. 
  Comparing creating time does not sound like a good idea to me.  If I 
remember correctly, we are trying to fix the problem in another RFE.

SSLSession.getId() returns the identifier assigned to this Session. 
While for a session, it is normally refer to the session negotiated for 
the full handshake.  For resuming session, the identifier should be the 
same.  There are might be compatibility issues if we don't use session 
id or use different session id for the resumed session.

Per RFC 5077, the full handshake uses a session ID, while resumption may 
use a empty Session ID in the ServerHello.  However, because of the 
SSLSession.getId() spec, I would prefer to keep using it and use the 
full handshake id for resumption.

Thanks,
Xuelei