Skip to main content

Transport Layer Security (TLS) Client Keyshare Extension
draft-bzwu-tls-client-keyshare-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Bingzheng Wu
Last updated 2015-04-28
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-bzwu-tls-client-keyshare-00
TLS                                                               BZ. Wu
Internet-Draft                                              Alibaba Inc.
Intended status: Standards Track                          April 28, 2015
Expires: October 30, 2015

        Transport Layer Security (TLS) Client Keyshare Extension
                   draft-bzwu-tls-client-keyshare-00

Abstract

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 30, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Wu                      Expires October 30, 2015                [Page 1]
Internet-Draft        TLS Client Keyshare Extension           April 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Client Keyshare Extension . . . . . . . . . . . . . . . . . .   4
     3.1.  Extension-data Specification  . . . . . . . . . . . . . .   4
     3.2.  Message Flow with This Extension  . . . . . . . . . . . .   5
   4.  Interaction . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   A full TLS handshake as specified in TLS [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.

   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.

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

   The message flow of normal full handshake is illustrated in Figure 1;
   and the message flow of handshake using this extension is illustrated
   in Figure 2.

Wu                      Expires October 30, 2015                [Page 2]
Internet-Draft        TLS Client Keyshare Extension           April 2015

         Client                                               Server

         ClientHello                  -------->
                                                         ServerHello
                                                        Certificate*
                                                  ServerKeyExchange*
                                                 CertificateRequest*
                                      <--------      ServerHelloDone
         Certificate*
         ClientKeyExchange
         CertificateVerify*
         [ChangeCipherSpec]
         Finished                     -------->
                                                  [ChangeCipherSpec]
                                      <--------             Finished
         Application Data             <------->     Application Data

         Figure 1 [TLSv1.2].  Message flow of normal full handshake

         Client                                               Server

         ClientHello                  -------->
         {with client_keyshare extension}
                                                         ServerHello
                                                        Certificate*
                                                   ServerKeyExchange
                                                  [ChangeCipherSpec]
                                      <--------             Finished
         [ChangeCipherSpec]
         Finished                     -------->
         Application Data             <------->     Application Data

                 Figure 2 Message flow using this extension

   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.

   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

Wu                      Expires October 30, 2015                [Page 3]
Internet-Draft        TLS Client Keyshare Extension           April 2015

   better than RSA (TLS version 1.3, which works in progress, is going
   to remove support for RSA key exchange).

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

   Besides, this extension does not work if server requests client's
   certificate, which also need 1 RTT.

   Finally, this extension only works in full handshake, while not in
   abbreviated handshake which does not need key exchange.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

3.  Client Keyshare Extension

   This document defines a new extension type (client_keyshare(TBD)),
   which is used in ClientHello and ServerHello messages.  The extension
   type is specified as follows.

            enum {
                 client_keyshare(TBD), (65535)
            } ExtensionType;

3.1.  Extension-data Specification

   The extension_data field of this extension, when included in the
   ClientHello, MUST contain the ClientKeyshare structure, which offers
   one or more ClientKeyShareOffer values, each representing 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
   [TLSv1.2], to indicate client's preferences.

   Only NamedCurves [TLSECC] (for EC type) and NegotiatedParameters
   (which works in progress) (for FF type) are supported.  While generic
   parameters are not supported for safety and simplicity.

Wu                      Expires October 30, 2015                [Page 4]
Internet-Draft        TLS Client Keyshare Extension           April 2015

            struct {
                 ClientKeyShareOffer offers<0..2^16-1>;
            } ClientKeyShare;

            struct {
                 NamedGroup    group_id;
                 select (typeof(group_id)) {
                     case FF:  ClientDiffieHellmanPublic;
                     case EC:  ECPoint;
                 } public_key;
            } ClientKeyShareOffer;

   group_id
      Specifies the DH parameters associated with the public key.
      NamedGroup is extended from NamedCurve [TLSECC] by Negotiated
      Finite Field Diffie-Hellman Ephemeral Parameters for TLS, which
      works in progress, for supporting finite-field-based DH.

   public_key
      The ephemeral DH public key.  It's in ClientDiffieHellmanPublic
      format [TLSv1.2] for FF type, or in ECPoint format [TLSECC] for EC
      type.

   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 this
   session.

3.2.  Message Flow with This Extension

   In TLS handshake, client adds this extension in ClientHello, with one
   or more DH keyshares.

   When receiving handshake, server enables this extension if (also
   described in Introduction session):

   -  this extension is present in ClientHello;

   -  the negotiated key-exchange algorithm is DH-like;

   -  at least one acceptable ClientKeyShareOffer;

   -  client's certificate is not required;

   -  and it's full handshake but not abbreviated.

   If enabled, the server then:

Wu                      Expires October 30, 2015                [Page 5]
Internet-Draft        TLS Client Keyshare Extension           April 2015

   -  adds this extension in ServerHello with empty extension_data, to
      indicate enable this extension;

   -  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;

   -  and does not wait for ClientKeyExchange, or sends ServerHelloDone;
      but sends ChangeCipherSpec and Finished immediately.  It's like
      the abbreviated handshake flow.

   The client enables this extension if the server echos this extension
   in ServerHello.

   If enabled, the client then:

   -  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;

   -  does not send ClientKeyExchange;

   -  and expects not ServerHelloDone but ChangeCipherSpec and Finished
      after ServerKeyExchange.  It's like the abbreviated handshake
      flow.

4.  Interaction

   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 [TICKET].

   In Session Hash extension, which works in progress,
   "handshake_messages" refers 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.

   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.

Wu                      Expires October 30, 2015                [Page 6]
Internet-Draft        TLS Client Keyshare Extension           April 2015

5.  Security Considerations

   This extension brings client's DH keyshare forward, from
   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.

6.  IANA Considerations

   IANA is requested to add an entry to the existing TLS ExtensionType
   registry, defined in TLS [TLSv1.2], for client_keyshare(TBD) defined
   in this document.

7.  References

   [KEYWORDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [TICKET]   Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [TLSv1.2]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Author's Address

   Bingzheng Wu
   Alibaba Inc.

   EMail: bingzheng.wbz@alibaba-inc.com

Wu                      Expires October 30, 2015                [Page 7]