RFR 8206929: Check session context for TLS session resumption

[Xuelei Fan]

I think we need to check more aspects, for both the session resumption 
producer and consumer:
1. the local is able to resume the session.
2. the peer is able to resume the session.
3. the change of the security parameters does not impact the resumption.

So, for the protocol version checking in server side:
1. the client requested to use the negotiated version.
2. the server still supports the negotiated version.

I think #2 is get checked in line 406-414 block.  Did we check #1 in 
somewhere else?

For the cipher suite checking in server side:
1. the client requested to use the negotiate cipher suite.
2. the server still supports the negotiated cipher suite.

I think #2 is get checked in line 445-453 block.  Did we check #1 in 
somewhere else?


For the signature algorithms checking in server side:
1. the client requested to use the algorithms used in full handshake
2. the server still supports the algorithms used in full handshake

The algorithms used in full handshake is one element or a subset of the 
local and peer supported algorithms.   We may not cache the used 
algorithms in the session.  But it is acceptable to me to use defensive 
policy that we don't allow session resumption if the supported 
algorithms get changed (as you did in the webrev to use 
Collection.containsAll() line 435).

As reminded me that we may also want to check for both the 
signature_algorithms and signature_algorithms algorithms.

I think #2 is get checked in line 431-442 block.  Did we check #1 in 
somewhere else?

On 7/13/2018 9:10 AM, Adam Petcher wrote:
> On 7/13/2018 11:34 AM, Xuelei Fan wrote:
> 
>> PreSharedKeyExtension.java
>> --------------------------
>> The local supported signature algorithms are checked in the 
>> canRejoin() method.  Should the peer supported signature algorithms be 
>> checked as well?
> 
> I don't think so. When the peer creates its PreSharedKeyExtension, it 
> should only offer sessions (i.e. PSK identities) that it is willing to 
> resume. This includes checking for its supported signature algorithms, 
> or any checks that are required by its policy.
I see your point.  But the peer is not trustworthy so that we normally 
validate the input to make sure the peer is doing the right thing.

Thanks,
Xuelei

> If the server gets a PSK 
> identity from the client, then server should use that PSK to resume a 
> session as long as it is acceptable according to the server's policy. 
> Trying to figure out the peer's policy and enforce it is error prone and 
> adds unnecessary complexity.
> 
> Though maybe I'm missing some other motivation to add this check.