Internet DRAFT - draft-bzwu-tls-client-keyshare
draft-bzwu-tls-client-keyshare
TLS BZ. Wu
Internet-Draft Alibaba Inc.
Intended status: Standards Track May 5, 2015
Expires: November 6, 2015
Transport Layer Security (TLS) Client Keyshare Extension
draft-bzwu-tls-client-keyshare-01
Abstract
This document defines an extension that allows a TLS client to carry
Diffie-Hellman (DH) keyshares in ClientHello message, replacing the
ClientKeyExchange message in the second round-trip, to reduce the
full handshake latency to 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 November 6, 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 November 6, 2015 [Page 1]
Internet-Draft TLS Client Keyshare Extension May 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Client Keyshare Extension . . . . . . . . . . . . . . . . . . 3
3.1. Extension Type . . . . . . . . . . . . . . . . . . . . . 3
3.2. Extension-data Specification . . . . . . . . . . . . . . 3
3.3. Message Flow with This Extension . . . . . . . . . . . . 4
4. Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
A full TLS handshake as specified in [TLSv1.2] requires 2-RTT, mostly
because of the ClientKeyExchange message in the second round-trip,
which is used for the key exchange. TLS 1.3, which works in
progress, 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.
This document defines a TLS extension that allows a client using TLS
1.2 to carry DH keyshares in the ClientHello message with the first
round-trip. The client and server complete key exchange by the
keyshares and native ServerKeyExchange message, thus the
ClientKeyExchange message is not necessary and could be omitted.
This leads to a latency reduction of one round-trip.
This extension is intended for TLS 1.2 only, but no previous versions
[TLSBCP]. This extension only supports Ephemeral DH, but no static
DH [TLSBCP]. This extension supports Elliptic Curve (EC) and Finite
Field (FF) keyshare types. Only NamedCurves [TLSECC] (for EC type)
and NegotiatedParameters (work in progress) (for FF type) are
supported, while generic parameters are not supported for safety and
simplicity. This extension dose not work if client certificates are
involved, which needs the second round-trip too.
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].
Wu Expires November 6, 2015 [Page 2]
Internet-Draft TLS Client Keyshare Extension May 2015
3. Client Keyshare Extension
3.1. Extension Type
This document defines a new extension type (client_keyshare(TBD)),
which is used in the ClientHello and ServerHello messages. The
extension type is specified as follows.
enum {
client_keyshare(TBD), (65535)
} ExtensionType;
3.2. Extension-data Specification
The extension_data field of this extension, when included in the
ClientHello message, 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 as with elliptic_curves extension
[TLSv1.2], to indicate client's preference.
struct {
ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare;
struct {
byte type(3);
NamedGroup group_id;
select (typeof(group_id)) {
case FF: ClientDiffieHellmanPublic;
case EC: ECPoint;
} public_key;
} ClientKeyShareOffer;
type
Since only NamedCurves and NegotiatedParameters are supported in
this extension, this byte exists only for compatibility with
ECCurveType in ECParameters [TLSECC], and its value MUST always be
3.
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 (work in
progress) to support finite-field-based DH.
Wu Expires November 6, 2015 [Page 3]
Internet-Draft TLS Client Keyshare Extension May 2015
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 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.
3.3. Message Flow with This Extension
In brief, the full handshake works as follows with this extension. A
client takes this extension with some DH keyshares in the ClientHello
message. A server receiving this extension echoes 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, the server sends no ServerHelloDone, but
ChangeCipherSpec and Finished message immediately, similar to an
abbreviated handshake flow.
The message flow is illustrated in the this figure.
Client Server
ClientHello -------->
{with client_keyshare extension}
ServerHello
Certificate*
ServerKeyExchange
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
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.
This extension only works if the negotiated key exchange algorithm is
Ephemeral Diffie-Hellman (FFDHE or ECDHE). 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
Wu Expires November 6, 2015 [Page 4]
Internet-Draft TLS Client Keyshare Extension May 2015
(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 [TLSBCP]
Since the client does not know which DH types and parameters the
server supports, it MAY takes more than one DH keyshare in this
extension. The server picks one DH keyshare of the same type as with
the key exchange algorithm (FF or EC) and acceptable parameters,
generates a DH keyshare with the same parameters, sends it in
ServerKeyExchange message, and completes the key exchange with these
two keyshares. If there is no suitable keyshare in client's
extension, the server MUST ignore this extension.
A client enables this extension only if the server echoes this
extension in the ServerHello message. The client picks the
ClientKeyShareOffer containing the same parameters as with
ServerKeyExchange. If there is no such ClientKeyShareOffer, the
client MUST abort the handshake with an illegal_parameter fatal
alert.
If this extension is enabled, a server does not wait for the
ClientKeyExchange, or send a ServerHelloDone message; instead it
sends ChangeCipherSpec and Finished messages immediately, like with
an abbreviated handshake. Accordingly a client dose not send
ClientKeyExchange or wait for ServerHelloDone message.
A server does not enable this extension if it requests client's
certificate, which needs the second round-trip too.
Finally, this extension only works in full handshake, while not in
abbreviated handshake which does not need key exchange.
4. Interaction
Server sends ChangeCipherSpec and Finished messages after the
ServerKeyExchange, if this extension is enabled. However there may
be messages between the ServerKeyExchange and ChangeCipherSpec, e.g.
NewSessionTicket, if the Session Ticket extension is used [TICKET].
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. 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.
Wu Expires November 6, 2015 [Page 5]
Internet-Draft TLS Client Keyshare Extension May 2015
5. Security Considerations
This extension brings client's DH keyshare forward, from the
ClientKeyExchange message in the second round-trip, to ClientHello
message in the first round-trip. TLS 1.3 (works in progress) also
works like this. So there should not be any security problem
introduced.
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. Acknowledgements
Thanks to Ilari Liusvaara and Aaron Zauner for their valuable
comments and suggestions on this draft.
8. 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.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", RFC 7525, May 2015.
[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 November 6, 2015 [Page 6]
