RFR 8226338: Updates to Stateless Resumption

Xuelei Fan xuelei.fan at oracle.com
Tue Jul 16 04:41:11 UTC 2019

> I will revert it. I'm not going to argue with you about this.. I thought 
> it might have provided better debugging.
>>   317 public byte[] produce(ConnectionContext context) ...
>>   324 public byte[] produce(ServerHandshakeContext shc) ...
>>   433 public byte[] produce(PostHandshakeContext hc) ...
>> I did not get the point to use three methods here.  Read more inlines, 
>> please.
> I had decided to separate them because I want multiple instanceOf 
> checks, but will merge them.
Not a concern of mine to separate them if necessary.  I thought it is 
related to the following bound values issue and did not get the idea.

>> On 7/15/2019 4:04 PM, Anthony Scarpino wrote:
>>> I've updated the webrev
>>> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.01/
>>> As I need to push this by wednesday, please review it soon.
>>> There are fixes for the comments that were made, added a NST for 
>>> boundVaules, a very basic test to make sure the post handshake NST is 
>>> sent after boundValues have changed.
>> Did you mean send a new NST of the boundValues is changed?  What if 
>> the previous NST was used for resumption?
> Yes.  It is up to the client to manage which NST it uses.  If you want 
> some mechanism of keeping track tickets.  It will have to go into 14.
Sorry for the confusing.  I did not mean to keeping track to tickets.

For TLS 1.2, I think the current update does not solve the boundVaules 
issue, right?  I see these lines in SSLSessionImpl.java.

1363    if (protocolVersion.useTLS13PlusSpec()) {
1364        updateNST = true;
1365    }

which limit the scope to TLS 1.3+ versions only.

Why sending a new NST solves the bound values problem?  I did not find 
the code that restores the bound values set after the handshaking in 
session resumption.  The bound values are still missed if using 
stateless ticket, right?  I may miss something.


> Update:
> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.02/
> Tony

More information about the security-dev mailing list