<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p>On 7/16/2018 3:04 PM, Xuelei Fan wrote:<br>

    </p>

    <blockquote type="cite"

      cite="mid:68363bfe-0f70-ef9f-065f-a1413d697f64@oracle.com">On

      7/16/2018 10:38 AM, Adam Petcher wrote:

      <br>

      <blockquote type="cite">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.

        <br>

      </blockquote>

      I did not get your point.  Would you mind describe it more?

      <br>

    </blockquote>

    Section 4.2.11 of the I-D:<br>

    <pre class="newpage">Each PSK is associated with a single Hash algorithm.  For PSKs

   established via the ticket mechanism (<a href="https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.6.1">Section 4.6.1</a>), 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.

</pre>

    and<br>

    <pre class="newpage">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".</pre>

    Section 4.6.1:<br>

    <pre class="newpage">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.</pre>

    <br>

    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. <br>

  </body>

</html>