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