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.
Xuelei
> Update:
> http://cr.openjdk.java.net/~ascarpino/8226338/webrev.02/
>
> Tony
More information about the security-dev
mailing list