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

From: Aaron Zauner <[email-masked]>
Date: Tue, 05 May 2015 22:26:37 +0200

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>

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 05 May 2015 23:01:49 +0200

A few more comments:

  * Maybe the document should state that it's intended for TLS 1.2 only
    (as there's no reason for this extension in 1.1).
  * Why have the original as well as the new flow as figures? Would
    just detail the new message flow with the proposed extension.
  * The security considerations section has barely any useful info.
  * it might suffice to note RSA as key exchange in the security
    considerations section, since it's deprecated
  * it might be reasonable to state in the beginning that handshakes
    involving client certificates are entirely unsupported, thus not
    noting it as often in the message flow section of the draft.

Aaron