Internet DRAFT - draft-bzwu-tls-ecdhe-keyshare

draft-bzwu-tls-ecdhe-keyshare







TLS                                                               BZ. Wu
Internet-Draft                                              Alibaba Inc.
Intended status: Standards Track                          April 24, 2015
Expires: October 26, 2015


        Transport Layer Security (TLS) ECDHE Keyshare Extension
                    draft-bzwu-tls-ecdhe-keyshare-00

Abstract

   This document defines an extension that allows a TLS client to carry
   Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) keyshare in
   ClientHello message, so as to reduce the full handshake latency of
   one network round-trip times (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 26, 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 26, 2015                [Page 1]

Internet-Draft        TLS ECDHE Keyshare Extension            April 2015


Table of Contents

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

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 [draft] which works in progress, supports only ECDHE mode for key
   exchange and provides 1-RTT mode, by sending ECDHE 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 an TLS extension that allows the client using
   current TLS version to carry ECDHE keyshare in ClientHello message in
   the 1st round-trip.  This leads to a latency reduction of 1-RTT.

   The full handshake looks as follows with this extension.  A client
   takes this extension with ECDHE keyshare in ClientHello message.  A
   server receiving this extension echos in ServerHello message to
   declare enable it in this session, and sends ServerKeyExchange to
   complete key exchange (with the ECDHE 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 flow of resumed session.

   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 26, 2015                [Page 2]

Internet-Draft        TLS ECDHE 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 ecdhe_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.

   Since the client does not know which elliptic curves the server
   supports, it MAY takes more than one ECDH keyshares in this
   extension.  The server picks an acceptable one if any; otherwise the
   server just ignores this extension.

   This extension only works if the negotiated key exchange algorithm is
   ECDHE.  Obviously client has to send ClientKeyExchange after getting



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


   server's certificate if using RSA as key exchange, so it can not
   benifit from this extension.  And other modes, such as ECDH-static,
   DH and DHE [TLSv1.2], are rarely used in practice, because of
   performance or security.  In fact the new version, TLS verion 1.3
   [draft] which works in progress, supports only ECDHE for key
   exchange.  So we support only ECDHE by now for simple.  [[OPEN ISSUE:
   Should we add support for ECDH-static, DH or DHE?]]

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

   Finally, this extension only works on full handshake, while not in
   resumed session 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.  ECDHE Keyshare Extension

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

            enum {
                 ecdhe_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 ECDH key agreement parameters.  The shares for each
   ClientKeyShareOffer MUST be generated independently.  Clients MUST
   NOT offer multiple ClientKeyShareOffers for the same parameters.

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

            struct {
                 ECParameters    curve_params;
                 ECPoint         public;
            } ClientKeyShareOffer;




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


   curve_params
      Specifies the elliptic curve domain parameters associated with the
      ECDH public key.

   public
      The ephemeral ECDH public key.

   The ECParameters and ECPoint structures are defined in [TLSECC].

   When included in ServerHello, this extension just means enable in
   this session, so the extension_data is empty.

3.2.  Message Flow with This Extension

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

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

   -  this extension exists in ClientHello;

   -  at least one acceptable ClientKeyShareOffer;

   -  the negotiated key-exchange algorithm is ECDHE;

   -  client's certificate is not required;

   -  and this session is not resumed.

   If enable, the server then:

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

   -  picks one acceptable ClientKeyShareOffer for key exchange,
      generates an ECDHE keyshare with the same ECParameters 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 flow of resumed session.

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

   If enable, the client then:



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


   -  picks one ClientKeyShareOffer with the same ECParameters in
      received ServerKeyExchange, and completes key exchange with the
      ClientKeyShareOffer and ServerKeyExchange.  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 flow of resumed session.

4.  Security Considerations

   This extension brings client's ECDHE keyshare forward, from
   ClientKeyExchange message in the 2nd round-trip, to ClientHello
   message in the 1st round-trip.  The TLS version 1.3 [draft], which
   works in progress, also works like this.  So I have not find any
   security problem about this extension yet.

5.  IANA Considerations

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

6.  References

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

   [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 26, 2015                [Page 6]