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]