RFR 8211018: Session Resumption without Server-Side State

[Xuelei Fan]

>>> On 6/3/2019 5:42 PM, Anthony Scarpino wrote:
>>>> http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02 

>> ----------
>>   381             if (chc.localSupportedSignAlgs == null) {
>>   382                 chc.localSupportedSignAlgs =
>>   383                         SignatureScheme.getSupportedAlgorithms(
>>   384                                 chc.algorithmConstraints, 
>> chc.activeProtocols);
>>   385             }
>>   386
>>   387             // Make sure the list of supported signature 
>> algorithms matches
>>   388             Collection<SignatureScheme> sessionSigAlgs =
>>   389 chc.resumingSession.getLocalSupportedSignatureSchemes();
>>   390             if 
>> (!chc.localSupportedSignAlgs.containsAll(sessionSigAlgs)) {
>>   391                 if (SSLLogger.isOn && 
>> SSLLogger.isOn("ssl,handshake")) {
>>   392                     SSLLogger.fine("Existing session uses 
>> different " +
>>   393                             "signature algorithms");
>>   394                 }
>>   395                 return null;
>>   396             }
>>
>> I did not get the idea here.  Does the session signature algorithms 
>> impact the use of session ticket extension?
> 
> This was something I got from the 1.3 CHPreSharedKeyProducer.produce(). 
> I can remove it, should I remove it from PSK as well?

I did not get the idea of the similar code in 
CHPreSharedKeyProducer.produce() either.  I'm fine if you want to remove 
the block as well.


>> ----------
>>   426             // If no buffer or we are already using stateless 
>> resumption
>>   427             if (buffer == null || shc.statelessResumption) {
>>   428                 return;
>>   429             }
>> I did not follow the idea of the checking.  I think the buffer should 
>> never be null. For the 'shc.statelessResumption', as this method is to 
>> parse the session ticket in the ClientHello handshake message, there 
>> might be no chance to set the shc.statelessResumption yet for initial 
>> handshaking.
>>
> 
> The ST extension runs twice.  The CH consumer has resumption checking 
> before the extensions are consumed normally from getEnabledExtensions(). 
>   I wasn't able figure out how to remove ST from the consumption list, 
> so I used shc.statelessResumption.  If shc.statelessResumption is set, 
> it skips the consumption.  Because I already have the boolean, I used it 
> for this purpose.
> 
I see where you were from now.

It is similar to provider_versions extension in ClientHello.  Maybe, you 
can use a similar block (at line 1077-1078?) as the one in 
ClientHello.java, by exclude the ST extension for TLS 1.2:

1166             extTypes = shc.sslConfig.getExclusiveExtensions(
1167                     SSLHandshake.CLIENT_HELLO,
1168                     Arrays.asList(
1169                             SSLExtension.PSK_KEY_EXCHANGE_MODES,
1170                             SSLExtension.CH_PRE_SHARED_KEY,
1171                             SSLExtension.CH_SUPPORTED_VERSIONS));
1172             clientHello.extensions.consumeOnLoad(shc, extTypes);


>> ----------
>>   509             // Skip if extension is not provided
>>   510             if (!hc.sslConfig.isAvailable(SH_SESSION_TICKET)) {
>>   511                 return;
>>   512             }
>>
>> If the extension is not provided, but receive the NST handshake 
>> message from server, is it expected to terminate the connection with 
>> an unexpected_message" alert?
> 
> if shc.statelessResumption is false NST is not added as a consumer. 
> shc.statelessResumption is true when both sides sent their ST in the CH 
> & SH.
> 
So, do you mean will the return value of 
"hc.sslConfig.isAvailable(SH_SESSION_TICKET)" is always 'true'?  If this 
code block (510-512) is just for assurance, as if it is checked here, I 
may just send back an alert. Silently dispose the extension does not 
sound like a good logic here, although it should never happens as you 
have already checked everything.

>>
>> ----------
>>   514             // If the context does not allow stateless tickets, 
>> exit
>>   515             if (!((SSLSessionContextImpl)hc.sslContext.
>>   516 engineGetClientSessionContext()).statelessEnabled()) {
>>   517                 return;
>>   518             }
>>
>> Similar to above comment.
>>
>>
>> ----------
>> What's client behavior if the server response with ST in ServerHello, 
>> but does not send the NewSessionTicket handshake message?
> 
> Then no ticket is stored and the next session is a full handshake.
> 
>>
>> Did we need the HandshakeAbsence handler for NewSessionTicket 
>> handshake message?
> 
> I don't believe so.
> 
If I read correctly, the NewSessionTicket is not an optional handshake 
message.  If the server sent the ST extension in ServerHello, the 
NewSessionTicket must be present.

Besides the NewSessionTicket handshake message, there are also some 
other server behavior changes.  For example, the server may use empty 
session ID in the SH message.  These changes may lead to issues we are 
not aware of yet.  For safe, I would suggest to make sure the 
NewSessionTicket is present as if ST is present in SH.

Xuelei