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]
