<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Ping.<br>
    </p>
    <div class="moz-forward-container">--J<br>
      <br>
      -------- Forwarded Message --------
      <table class="moz-email-headers-table" cellspacing="0"
        cellpadding="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
            </th>
            <td>RFR JDK-8247630: Use two key share entries</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
            <td>Wed, 8 Jul 2020 15:57:15 -0700</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
            <td>Jamil Nimeh <a class="moz-txt-link-rfc2396E" href="mailto:jamil.j.nimeh@oracle.com"><jamil.j.nimeh@oracle.com></a></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      Hello all,<br>
      <br>
      This is a small enhancement to the TLS 1.3 client hello.  With
      this change JSSE will make a best-effort attempt to select the
      most-preferred XDH and ECDHE named group.  In most cases this will
      be x25519 and secp256r1.  This was done to help reduce the number
      of times our clients get HelloRetryRequests due to servers wanting
      secp256r1 when we would just assert x25519.<br>
      <br>
      The asserted key shares can be affected by different settings for
      the jdk.tls.namedGroups System property.  If x25519 and/or
      secp256r1 are missing, the next-most-preferred named group of that
      class will be selected.  If no other named group in that class is
      in the supported_groups extension, then it will be skipped.  In
      the unlikely event that no XDH or ECDHE supported group is
      asserted, then the client will assert one key share, the most
      preferred one out of the supported groups.<br>
      <br>
      This also fixes one minor spec compliance issue where we weren't
      throwing an exception when a server returned an illegal
      HelloRetryRequest with a named group that was in the original
      key_shares extension from the client hello.<br>
      <br>
      Webrev:
      <a class="moz-txt-link-freetext" href="https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/">https://cr.openjdk.java.net/~jnimeh/reviews/8247630/webrev.01/</a><br>
      <br>
      JBS: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8247630">https://bugs.openjdk.java.net/browse/JDK-8247630</a><br>
      <br>
      --Jamil<br>
      <br>
    </div>
  </body>
</html>