Re: [TLS] New Version Notification for draft-bzwu-tls-client-keyshare-00.txt

[Aaron Zauner <[e-mail]>]

Hi,

I talked to Bingzheng off-list and suggested a couple of changes. I've
made these editorial changes to enhance the readability of the draft as
well as some grammatical and style changes. The effective content
remains identical.

Diff in-line. I also opened a Pull Request on GitHub for these changes:
https://github.com/alibaba/client-keyshare/pull/1

Couple of comments:

  - the introduction is quite verbose and explicit, usually this is
    just a couple of paragraphs that give an overview
  - The draft references ephemeral DH a couple of times, maybe it
    should state somewhere explicitly that it only supports ephemeral
    DH due to TLS 1.3 and the current BCP for TLS?
  - I find the bullet-point explainations in the "message flow" section
    rather confusing

Thanks,
Aaron


diff --git a/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml
b/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml
index d4662e0..3e88fcf 100644
--- a/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml
+++ b/rfc-draft/draft-bzwu-tls-client-keyshare-00.xml
@@ -34,36 +34,35 @@

     <abstract>
       <t>This document defines an extension that allows a TLS client
-      to carry Diffie-Hellman (DH) keyshare in ClientHello message,
-      replacing ClientKeyExchange message in the 2nd round-trip,
-      so as to reduce the full handshake latency of one network
round-trip time (RTT).</t>
+      to carry a Diffie-Hellman (DH) keyshare in ClientHello message,
+      replacing the ClientKeyExchange message in the 2nd round-trip,
+      to reduce the full handshake latency to one network round-trip
time (RTT).</t>
     </abstract>
   </front>

   <middle>
     <section title="Introduction">
       <t>A full TLS handshake as specified in TLS <xref
target="TLSv1.2"/> requires 2-RTT,
-      mostly because of the ClientKeyExchange message in the 2nd
round-trip, which is
-      used for key exchange.
-      The new version, TLS version 1.3 which works in progress,
-      provides 1-RTT mode, by sending DH keyshare immediately
-      after ClientHello in the 1st round-trip, called ClientKeyShare
message.
-      However it will takes long time to finalize the draft and deploy.
</t>
-
-      <t>This document defines a TLS extension that allows the client
using current TLS
-      version to carry DH keyshares in ClientHello message in the 1st
round-trip.
-      This leads to a latency reduction of 1-RTT. Elliptic Curve (EC)
and Finite Field (FF)
-      keyshare types are supported.</t>
-
-      <t>The full handshake looks as follows with this extension.
-      A client takes this extension with DH keyshare in ClientHello
message.
-      A server receiving this extension echos in ServerHello message to
indicate enable
-      it in this session, and sends ServerKeyExchange to complete key
exchange
+      mostly because of the ClientKeyExchange message in the second
round-trip, which is
+      used for the key exchange.
+      TLS 1.3 will offer a 1-RTT mode by sending DH keyshare immediately
+      after the ClientHello in the first round-trip, called
ClientKeyShare message.
+      However, it will take a long time to finalize the draft and
deploy TLS 1.3.</t>
+
+      <t>This document defines a TLS extension that allows a client
using TLS 1.2
+      to carry DH keyshares in the ClientHello message with the 1st
round-trip.
+      This leads to a latency reduction of of one round-trip. Elliptic
Curve (EC)
+      and Finite Field (FF) keyshare types are supported.</t>
+
+      <t>The full handshake works as follows with the keyshare extension.
+      A client takes this extension with the DH keyshare in the
ClientHello message.
+      A server receiving this extension echos it in the ServerHello
message to indicate support
+      within this session and sends a ServerKeyExchange to complete the
key exchange
       (with the DH keyshare in client's extension).
-      Since there is no ClientKeyExchange to wait for, server sends no
ServerHelloDone,
-      but ChangeCipherSpec and Finished immediately, which is like the
abbreviated handshake flow.</t>
+      Since there is no ClientKeyExchange to wait for, the server sends
no ServerHelloDone,
+      but ChangeCipherSpec and Finished message immediately, similar to
an abbreviated handshake flow.</t>

-      <t>The message flow of normal full handshake is illustrated in
Figure 1; and the message
+      <t>The message flow of a normal full handshake is illustrated in
Figure 1; and the message
       flow of handshake using this extension is illustrated in Figure
2.</t>

       <figure><artwork align="left"><![CDATA[
@@ -106,31 +105,30 @@

       ]]></artwork></figure>

-      <t>For TLS extension mechanism, this extension works only if
client and server
-      both support it. For example, if a server who does not support
this extension
-      receives a ClientHello message with this extension, the server
just ignores it.</t>
+      <t>This works only if client and server
+      both support the extension. For example, if a server which does
not support this extension
+      receives a ClientHello message with this extension, the server
MUST ignore it.</t>

-      <t>This extension only works if the negotiated key exchange
algorithm is DH-like,
-      FFDH(Ephemeral) or ECDH(Ephemeral).
-      Obviously client has to send ClientKeyExchange after getting server's
-      certificate if using RSA as key exchange, so it can not benefit
from this
-      extension normally. Although the client may get server's
certificate before
-      handshake by Cached Infomation extension which works in progress, we
-      does not support RSA key exchange for simplicity, and that
DH-like is better
-      than RSA (TLS version 1.3, which works in progress, is going to
-      remove support for RSA key exchange). </t>
+      <t>This extension only works if the negotiated key exchange
algorithm is
+      Ephemeral Diffie-Hellman (FFDH or ECDH).
+      Obviously, the client has to send a ClientKeyExchange message
after getting the server's
+      certificate if it is using RSA as key exchange. Thus it can not
benefit from this
+      extension. Although the client may get server's certificate
before the
+      handshake by the Cached Infomation extension (work in progress), we
+      do not support RSA key exchange for simplicity. TLS 1.3 will
remove support for RSA
+      key-exchange entirely and RSA as key-exchange is discouraged
<xref target="TLSBCP"/> </t>

       <t>Since the client does not know which DH types and parameters
the server supports,
-      it MAY takes more than one DH keyshares in this extension.
+      it MAY takes more than one DH keyshare in this extension.
       The server picks one DH keyshare of the same type with the key
exchange
-      algorithm (FF or ECC) and acceptable parameters, used for key
exchange.
-      If there is no suitable keyshare, the server just ignores this
extension. </t>
+      algorithm (FF or ECC) and acceptable parameters, used for the key
exchange.
+      If there is no suitable keyshare, the server MUST ignore this
extension. </t>

-      <t>Besides, this extension does not work if server requests
client's certificate,
-      which also need 1 RTT. </t>
+      <t>This extension does not work if server requests a client's
certificate,
+      which also needs 1-RTT. </t>

-      <t>Finally, this extension only works in full handshake, while
not in abbreviated
-      handshake which does not need key exchange.</t>
+      <t>Finally, this extension only works in when full handshake are
used,  abbreviated
+      handshake are not supported.</t>

     </section>

@@ -144,7 +142,7 @@

     <section title="Client Keyshare Extension">
       <t>This document defines a new extension type
(client_keyshare(TBD)), which
-      is used in ClientHello and ServerHello messages.
+      is used in the ClientHello and ServerHello messages.
       The extension type is specified as follows.  </t>

       <figure><artwork><![CDATA[
@@ -161,11 +159,11 @@
      a single set of DH key agreement parameters.  The shares for each
      ClientKeyShareOffer MUST be generated independently. Clients MUST NOT
      offer multiple ClientKeyShareOffers for the same parameters.
-     The shares SHOULD keep the same order with elliptic_curves
-     extension <xref target="TLSv1.2"/>, to indicate client's
preferences.</t>
+     The shares SHOULD keep the same order as with elliptic_curves
+     extension <xref target="TLSv1.2"/>, to indicate client's
preference.</t>

      <t>Only NamedCurves <xref target="TLSECC"/> (for EC type) and
NegotiatedParameters
-     (which works in progress) (for FF type) are supported.
+     (work in progress) (for FF type) are supported.
      While generic parameters are not supported for safety and
simplicity.</t>

       <figure><artwork><![CDATA[
@@ -186,8 +184,8 @@
          <t hangText='group_id'><vspace blankLines='0'/>
          Specifies the DH parameters associated with the public key.
          NamedGroup is extended from NamedCurve <xref target="TLSECC"/>
-         by Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for TLS,
-         which works in progress, for supporting finite-field-based DH.</t>
+         by Negotiated Finite Field Diffie-Hellman Ephemeral Parameters
for TLS
+         (work in progress) for supporting finite-field-based DH.</t>
        </list></t>

        <t><list style="hanging">
@@ -197,9 +195,9 @@
          or in ECPoint format <xref target="TLSECC"/> for EC type.</t>
        </list></t>

-     <t>Because the key exchange is made by ClientKeyshare extension
and ServerKeyExchange message,
-     it's not need to take value in extension_data when included in
ServerHello.
-     The server just echo the extension with empty extension_data to
indicate enable it in
+     <t>Because the key exchange is made by the ClientKeyshare
extension and ServerKeyExchange message,
+     it's not necessary to parse values in extension_data if included
in the ServerHello message.
+     The server just echoes the extension with an empty extension_data
to indicate support in the current
      this session. </t>

       </section>
@@ -207,36 +205,36 @@

       <section title="Message Flow with This Extension">

-     <t>In TLS handshake, client adds this extension in ClientHello,
with one or more DH keyshares.</t>
+     <t>In the TLS handshake, the client adds this extension in the
ClientHello message, with one or more DH keyshares.</t>

-     <t>When receiving handshake, server enables this extension if
(also described in Introduction session):
+     <t>When receiving a handshake, a server enables this extension if:
        <list style="symbols">
-       <t>this extension is present in ClientHello;</t>
+       <t>the extension is present in ClientHello;</t>
        <t>the negotiated key-exchange algorithm is DH-like;</t>
-       <t>at least one acceptable ClientKeyShareOffer;</t>
-       <t>client's certificate is not required;</t>
-       <t>and it's full handshake but not abbreviated.</t></list>
+       <t>it has at least one acceptable ClientKeyShareOffer;</t>
+       <t>the client's certificate is not required;</t>
+       <t>and it's not an abbreviated handshake.</t></list>
      </t>

      <t>If enabled, the server then:
        <list style="symbols">
-       <t>adds this extension in ServerHello with empty extension_data,
to indicate enable this extension;</t>
-       <t>picks one acceptable ClientKeyShareOffer for key exchange,
-          generates an DH keyshare with the same parameters as the
picked ClientKeyShareOffer,
-          sends it in ServerKeyExchange, and completes the key exchange
with them;</t>
-       <t>and does not wait for ClientKeyExchange, or sends
ServerHelloDone; but sends ChangeCipherSpec
-	  and Finished immediately. It's like the abbreviated handshake flow.
</t></list>
+       <t>adds this extension in the ServerHello message with an empty
extension_data, to indicate support for this extension;</t>
+       <t>picks one acceptable ClientKeyShareOffer for the key exchange,
+          generates an DH keyshare with the same parameters as the
chosen ClientKeyShareOffer,
+          sends it in the ServerKeyExchange, and completes the key
exchange with these values;</t>
+       <t>it does not wait for ClientKeyExchange, and does not send a
ServerHelloDone message; instead the server
+        sends ChangeCipherSpec and Finished messages immediately, like
with an abbreviated handshake. </t></list>
      </t>

-     <t>The client enables this extension if the server echos this
extension in ServerHello.</t>
+     <t>The client enables this extension if the server echoes this
extension in the ServerHello message.</t>

      <t>If enabled, the client then:
        <list style="symbols">
-       <t>picks the ClientKeyShareOffer containing the same parameters
with ServerKeyExchange, to complete key exchange.
-          If there is no such ClientKeyShareOffer, client MUST abort
the handshake with an illegal_parameter fatal alert;</t>
+       <t>picks the ClientKeyShareOffer containing the same parameters
as with ServerKeyExchange.
+          If there is no ClientKeyShareOffer, the client MUST abort the
handshake with an illegal_parameter fatal alert;</t>
        <t>does not send ClientKeyExchange;</t>
-       <t>and expects not ServerHelloDone but ChangeCipherSpec and
Finished after ServerKeyExchange.
-          It's like the abbreviated handshake flow. </t></list>
+       <t>and expects no ServerHelloDone message but ChangeCipherSpec
and Finished messages after the ServerKeyExchange,
+          like with an abbreviated handshake. </t></list>
      </t>
       </section>

@@ -245,29 +243,27 @@

     <section title="Interaction">

-    <t>Server sends ChangeCipherSpec and Finished after
ServerKeyExchange, if this
-    extension is enabled, in Figure 2. However there may be any
messages between
-    ServerKeyExchange and ChangeCipherSpec, like NewSessionTicket
message if Session
-    Ticket extension works <xref target="TICKET"/>.</t>
+    <t>Server sends ChangeCipherSpec and Finished messages after the
ServerKeyExchange, if this
+    extension is enabled (Figure 2). However there may be messages
between the
+    ServerKeyExchange and ChangeCipherSpec, e.g. NewSessionTicket, if
the Session
+    Ticket extension is used <xref target="TICKET"/>.</t>

-    <t>In Session Hash extension, which works in progress,
"handshake_messages"
-    refers to all handshake messages up to and including the
ClientKeyExchange message.
+    <t>With the Session Hash extension (work in progess)
"handshake_messages"
+    refer to all handshake messages up to and including the
ClientKeyExchange message.
     There is no ClientKeyExchange if this client_keyshare extension is
enabled.
-    So the "handshake_messages" should be changed to refer to all
handshake messages
-    up to and including the ServerKeyExchange message, without break
Session Hash extension. </t>
+    The "handshake_messages" should be changed to refer to all
handshake messages
+    up to and including the ServerKeyExchange message, without breaking
the Session Hash extension. </t>

     <t>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
-    where the FF NegotiatedParameters are defined, which works in
progress, only supports
-    FFDH-ephemeral but not FFDH-static. This extension dose too. </t>
-
+    where the FF NegotiatedParameters are defined (works in progress)
only supports
+    FFDH-ephemeral but not FFDH-static. This extension does as well
too. </t>
     </section>


     <section title="Security Considerations">
-    <t>This extension brings client's DH keyshare forward, from
ClientKeyExchange
+    <t>This extension brings client's DH keyshare forward, from the
ClientKeyExchange
     message in the 2nd round-trip, to ClientHello message in the 1st
round-trip.
-    The TLS version 1.3, which works in progress, also works like this.
-    So I have not find any security problem about this extension yet. </t>
+    The TLS version 1.3 (works in progress) also works like this. </t>
     </section>


@@ -333,6 +329,18 @@
       <seriesInfo name='RFC' value='5077' />
       <format type='TXT' target='https://tools.ietf.org/rfc/rfc5077.txt' />
     </reference>
+
+    <reference anchor='TLSBCP'>
+      <front>
+      <title>Recommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)</title>
+      <author initials='Y.' surname='Sheffer' fullname='Yaron Sheffer' />
+      <author initials='R.' surname='Holz' fullname='Ralph Holz' />
+      <author initials='P.' surname='Saint-Andre' fullname='Peter
Saint-Andre' />
+      <date year='2015' month='May' />
+      </front>
+      <seriesInfo name='RFC' value='7525' />
+      <format type='TXT' target='https://tools.ietf.org/rfc/rfc7525.txt' />
+    </reference>
    </references>

   </back>