RFR 8211018: Session Resumption without Server-Side State

[Anthony Scarpino]

On 6/4/19 10:02 AM, Xuelei Fan wrote:
> 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


An existing interop test, different from the test commented here, was 
looking at session id's for tls 1.3 and failing before my changes.  When 
I made some changes to use the creation time, the test started working.

John's comment is added session id checking to this test.  I'd rather 
not add that because it was not their before, and it is not reliable.

If there is an RFE to change this all, that is fine.  I'm just not going 
to address it here.

Tony