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.
