RFR 8206929: Check session context for TLS session resumption

[Adam Petcher]

On 7/16/2018 3:04 PM, Xuelei Fan wrote:

> On 7/16/2018 10:38 AM, Adam Petcher wrote:
>> Note that the relationship between sessions/PSKs and cipher suites is 
>> different in TLS 1.2 vs 1.3. In TLS 1.3, the cipher suite doesn't 
>> need to match---only the hash algorithm needs to match.
> I did not get your point.  Would you mind describe it more?
Section 4.2.11 of the I-D:

Each PSK is associated with a single Hash algorithm.  For PSKs
    established via the ticket mechanism (Section 4.6.1 
<https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.1>), this is the KDF
    Hash algorithm on the connection where the ticket was established.
    For externally established PSKs, the Hash algorithm MUST be set when
    the PSK is established, or default to SHA-256 if no such algorithm is
    defined.  The server MUST ensure that it selects a compatible PSK (if
    any) and cipher suite.

and

Clients MUST verify that the server's selected_identity is within the
    range supplied by the client, that the server selected a cipher suite
    indicating a Hash associated with the PSK and that a server
    "key_share" extension is present if required by the ClientHello
    "psk_key_exchange_modes".

Section 4.6.1:

Any ticket MUST only be resumed with a cipher suite that has the same
    KDF hash algorithm as that used to establish the original connection.


So the ticket/PSK only has an associated hash algorithm, and the 
connection may use the PSK with any cipher suite as long as the hash 
algorithm is the same (unless I am missing some constraints in the RFC). 
As our implementation is now, the PSK may only be used if it has the 
same cipher suite as the session that created it. If the client/server 
no longer supports the cipher suite of the session that created the PSK, 
but it supports some other cipher suite with the same hash, then the 
session will not be resumed, even though the standard allows it to be 
resumed using another cipher suite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180716/b9fac805/attachment.htm>