Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: December 20, 2010                                 June 18, 2010

               Transport Layer Security (TLS) Snap Start


   This document describes a Transport Layer Security (TLS) extension
   for eliminating the latency of handshakes when the client has prior
   knowledge about the server.  Unlike resumption, this prior knowledge
   is not secret and may be obtained from third parties and stored on
   disk for significant periods of time.

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

   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 December 20, 2010.

Copyright Notice

   Copyright (c) 2010 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
   ( 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.

Langley                 Expires December 20, 2010               [Page 1]

Internet-Draft               TLS Snap Start                    June 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Design . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Details  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  7
   5.  Snap Start Extension . . . . . . . . . . . . . . . . . . . . .  8
   6.  Active attack considerations . . . . . . . . . . . . . . . . . 11
   7.  Requirements on the application  . . . . . . . . . . . . . . . 12
   8.  Interactions with the Session Tickets extension  . . . . . . . 13
   9.  Interactions with OCSP stapling  . . . . . . . . . . . . . . . 14
   10. Interactions with client certificates  . . . . . . . . . . . . 15
   11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   12. Prior work . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   15. Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22

Langley                 Expires December 20, 2010               [Page 2]

Internet-Draft               TLS Snap Start                    June 2010

1.  Introduction

   Snap Start aims to remove the latency overhead of TLS handshakes in
   the case that the application protocol involves the client speaking
   first.  Currently, TLS handshaking imposes additional latency and is
   costly for time-sensitive applications.

   In order to achieve this, the initial flow from the client must
   contain application data and, therefore, everything needed for the
   server to complete a handshake and process it.  Starting from this
   premise we can derive the essential features of Snap Start.

Langley                 Expires December 20, 2010               [Page 3]

Internet-Draft               TLS Snap Start                    June 2010

2.  Design

   At first we are only considering the case of a full handshake.
   Assume, for the sake of argument, a client that is capable of
   predicting the contents of a server's first handshake flow (i.e. the
   "ServerHello" message through to the "ServerHelloDone").  Such a
   client could send "ClientKeyExchange", "ChangeCipherSpec" and
   "Finished" messages immediately following its "ClientHello".  It
   would then be able to transmit application data records and we have
   successfully eliminated the TLS handshake latency.

   However, several elements of the server's first handshake flow are
   unpredictable.  Fundamentally, any ephemeral Diffie-Hellman based
   cipher suite is incompatible with Snap Start so the following assumes
   that the server is using non-ephemeral key agreement.

   The chosen cipher suite, compression method, supported extensions,
   ordering of those extensions, certificate etc are all somewhat
   unpredictable for a given server but are highly correlated across
   time.  Given a previous handshake with the same server, assuming that
   it will make the same choices when presented with a similar
   "ClientHello" is sufficiently accurate to expect a very high rate of
   prediction of these elements of the handshake.

   The server's chosen session id is unpredictable.  However, this can
   be eliminated by using Session Tickets [RFC5077].  When Session
   Tickets are in use the "ServerHello" doesn't include a session id and
   the "NewSessionTicket" message itself is not part of the first flow.

   Lastly, the "server_random" is unpredictable.  The "server_random"
   exists to provide uniqueness and freshness.  When the server picks a
   random value it can be assured that no previous TLS connection has
   ever used the same value.  Therefore the connection cannot be a
   replay of the client's traffic.  Additionally, the server knows when
   its unpredictable random value was created, relative to its local
   clock, and therefore knows that handshake hasn't been delayed for an
   arbitrary amount of time.

   In order for the "server_random" to be predictable by the client, it
   will have to be chosen by the client and suggested to the server.  In
   order for the server to be assured of uniqueness, it will have to
   remember every "server_random" value that has been used so that it
   may reject duplicates.  (Several methods of limiting the amount of
   state required for this are introduced below.)

   Even without Snap Start, an attacker can delay an application data
   record in an established connection.  However, both parties to the
   connection are likely to timeout after some period of inactivity,

Langley                 Expires December 20, 2010               [Page 4]

Internet-Draft               TLS Snap Start                    June 2010

   bounding the amount of possible delay introduced.  With Snap Start,
   since we are assuming that the client's initial flow includes a full
   handshake and application data, an attacker could arbitrarily delay
   the flow and have the server process the application data at a time
   of their choosing.  As the server lacks an nonce it has no way of
   detecting this.

   Without a similar mechanism to bound the delay of a Snap Start
   handshake, an attacker could perform a pseudo-replay attack: a
   handshake is delayed until the client retries, but the first
   handshake can still be used to deliver the same application data a
   second time.  Because of this (and for other reasons other reasons
   given below) we require some degree of clock synchronisation between
   the client and server with respect the the timestamp in the
   "ClientHello".  The level of synchronisation required is left to the
   application layer to determine although it's recommended that the
   permitted clock skew be shorter than the application's retry timeout.

Langley                 Expires December 20, 2010               [Page 5]

Internet-Draft               TLS Snap Start                    June 2010

3.  Details

   The essential features of Snap Start are now established: the client
   predicts the server's handshake flow using a client suggested
   "server_random", SessionTickets and knowledge from a previous
   connection to the same server.

   We now note that this functions for both full and abbreviated
   handshakes.  The abbreviated handshake retains its lower
   computational requirements but both now complete in the same number
   of round trips.

   In order to limit the amount of state required for the server to
   reject repeated "server_random"s, we allow the server to bound this
   state temporally and spatially.  In the temporal dimension, we define
   that the "gmt_unix_time" of the server random is taken from
   "gmt_unix_time" of the client's random value.  The server may use
   this timestamp to reject all suggested random values outside some
   window around the current time.

   Spatially, we define that the subsequent eight bytes of the server's
   random value are the server's 'orbit' value.  This value must be
   discovered by the client from a previous (non Snap Start) handshake.
   In the event that several, geographically separated servers share the
   same certificates, they may use different orbit values.  This allows
   one to reject "server_random" values for the other without any
   communication between them.  (The term 'orbit' was chosen only to be
   short and otherwise reasonably meaningless in this context.)

Langley                 Expires December 20, 2010               [Page 6]

Internet-Draft               TLS Snap Start                    June 2010

4.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Langley                 Expires December 20, 2010               [Page 7]

Internet-Draft               TLS Snap Start                    June 2010

5.  Snap Start Extension

   A new extension type ("snap_start(TBD)") is defined and MAY be
   included by the client in its "ClientHello" message.  If, and only
   if, the server sees this extension in the "ClientHello", it MAY
   choose to include the extension in its "ServerHello".

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

   The "extension_data" field of a "snap_start" extension in a
   "ClientHello" MAY be empty.

   If the server chooses to echo a "snap_start" extension then it is
   indicating that it MAY support Snap Start on future connections.  The
   contents of the "extension_data" in this case MUST be:

   struct {
     opaque orbit[8];
     CipherSuite snap_start_cipher_suite;
   } ServerSnapStart;

   "orbit" is the server's current orbit value and
   "snap_start_cipher_suite" contains the CipherSuite value that the
   client should assume that the server will use in a Snap Start

   If the client wishes to attempt a Snap Start connection then it
   includes a non-empty "snap_start" extension in its "ClientHello".  If
   the extension is not empty, then its contents MUST be:

   struct {
     opaque orbit[8];
     opaque random_bytes[20];
     opaque predicted_server_handshake[8];
     // TLSCiphertext structures follow
   } ClientSnapStart;

   Following this, without a length prefix, the client may include one
   or more "TLSCiphertext" structures to be processed by the server in
   the case that the Snap Start is successful.  These records are as
   described in RFC 5246 [RFC5246] section 6.2

   The "orbit" MUST contain an orbit value obtained from a previous
   connection to the same server. "random_bytes" MUST contain 20 random
   bytes from a cryptographic random source equal in strength to the one
   used for the "client_random".

Langley                 Expires December 20, 2010               [Page 8]

Internet-Draft               TLS Snap Start                    June 2010

   "predicted_server_handshake" MUST contain an FNV1a64 [fnv1a] hash of
   the server's predicted response flow.  This hash is taken over the
   bytes of the "Handshake" structures, as defined in RFC 5246 section 
   7.4.  If the client is attempting to resume a connection then this is
   calculated over the server's "ServerHello" message.  Otherwise, this
   is calculated over all handshake messages from the "ServerHello" to
   the "ServerHelloDone" (inclusive).  The client's prediction MUST
   assume that the server chooses its server random as detailed below.
   The client's prediction MUST also assume that the server includes a
   Snap Start extension with the same "ServerSnapStart" contents as
   previously observed.

   If the client's prediction is correct then the server MAY perform a
   Snap Start handshake.  If the server wishes to perform a Snap Start
   handshake then it MUST form its "random" value from the
   "gmt_unix_time" of the client's "random", followed by the server's
   orbit value, followed by the contents of "random_bytes" from the
   client's Snap Start extension.

   The server MUST NOT transmit any predicted handshake messages and
   MUST start processing records from the client's Snap Start extension.
   For the purposes of the Finished calculation, the client's
   "ClientHello" is hashed as if the "snap_start" extension were not
   included (the "length" field of the "Handshake" structure from RFC
   5246 section 7.4, and the prefixed length of the "extensions" member
   of the "ClientHello" are updated accordingly).  When processing
   records from the extension, they are hashed as usual.  Once the set
   of records embedded in the "ClientHello" has been exhausted, the
   server resumes reading records from the network.  Records must not be
   partially contained within the "ClientHello" and partially read from
   the network.

   (Since the "ClientHello" is likely to have a "Finished" message
   embedded within it, it cannot be hashed into the Finished calculation
   as normal as its contents would then depend in its own hash.  One
   could consider hashing with the embedded hash zeroed out, however a
   "Finished" message is encrypted under the negotiated cipher suite and
   a CBC-based ciphersuite would spread the effects of the embedded hash
   beyond its apparent boundaries.  Likewise, the "Finished" message is
   compressed using the negotiated compression algorithm thus the length
   of the record, and thus the extension, depend on the contents of the
   hash.  Given these limitations, removing the extension altogether is
   the simplest way to break the cycle.)

   If the server chooses not to perform a Snap Start handshake (for any
   reason, including that the application rejected the suggested random
   value or that the client mispredicted the handshake) then the
   handshake MUST continue as normal.  The server MUST NOT change the

Langley                 Expires December 20, 2010               [Page 9]

Internet-Draft               TLS Snap Start                    June 2010

   way that it hashes the "ClientHello".  The server MAY echo a
   "snap_start" extension.

Langley                 Expires December 20, 2010              [Page 10]

Internet-Draft               TLS Snap Start                    June 2010

6.  Active attack considerations

   Given that this draft makes changes to the Finished hash, it's
   required to show that no active attack can cause a handshake to
   complete which differs from that which would have occurred otherwise.

   Since the "snap_start" extension is not included in the Finished hash
   of a Snap Start handshake, we have to consider the results of an
   attacker manipulating its contents.

   Firstly, since the embedded records are hashed as usual, the same
   security properties hold: any manipulation will be detected by the
   Finished hash, or by a MAC verification failure.

   An attacker could manipulate the orbit.  This would typically cause
   the server to reject the suggested random value and a normal
   handshake would detect the manipulation.  In the case that the server
   still proceeds with a Snap Start handshake, the orbit is copied into
   the "server_random" in the "ServerHello", which is then hashed into
   the Finished calculation (although not transmitted).

   An attacker could manipulate the suggested server random.  The same
   argument as for the orbit holds here.

   An attacker could manipulate the hash of the predicted messages.
   Assuming that the client correctly predicted the hash, the
   manipulation would cause the server to not perform a Snap Start
   handshake and the manipulation would be detected.  Assuming that the
   client mispredicted, and that the manipulation results in a
   different, but also incorrect, value then the same argument applies.
   Assuming that the client mispredicted and the manipulation corrects
   the hash, the server could perform a Snap Start handshake, but the
   differing contents of the predicted handshake messages will be hashed
   into the Finished calculation and the manipulation will be detected.

Langley                 Expires December 20, 2010              [Page 11]

Internet-Draft               TLS Snap Start                    June 2010

7.  Requirements on the application

   Applications are required to ensure that no suggested random value is
   accepted twice within the scope of any given certificate.  In
   general, validation of the suggested random value is outside the
   scope a TLS implementation (although it may handle simple cases and
   provide utility code for others).  Applications may use the orbit
   value and client timestamp to aid them in this.  Applications may
   always safely reject a suggested random value.  Applications SHOULD
   limit the allowed difference between the timestamp in the suggested
   random value and the current time in order to prevent arbitrary
   delays, as detailed in the design section of this document.

   For a single server deployment, the server may generate a new, random
   orbit value each time that it starts and, thereafter, maintain an in-
   memory data structure.  Each random value seen should be "struck off"
   by recording it in this data structure (the "strike register").  The
   strike register's size can be bound by fixed limits and by rejecting
   all random values where the timestamp is outside a certain window
   around the current time.

   For a multi-server deployment in a single location, the servers
   should share an orbit value and a strike register.  The strike
   register is likely to be a held in a single location which the TLS
   servers access over an internal network.

   For a multi-cluster deployment, where the clusters are geographically
   separated, each cluster should have its own orbit value and shared
   strike register.  The effectiveness of Snap Start in this setup is
   limited by the probability of a given client repeatedly being served
   by the same cluster.  With pure round robin scheduling, a Snap Start
   handshake is unlikely to be successful.

Langley                 Expires December 20, 2010              [Page 12]

Internet-Draft               TLS Snap Start                    June 2010

8.  Interactions with the Session Tickets extension

   A successful Snap Start abbreviated handshake can occur without the
   use of session tickets.  A successful Snap Start full handshake,
   without session tickets, can only occur if the server doesn't
   generate a random session id.  A server MAY choose not to generate a
   session id if the client presents a Snap Start extension but not a
   session tickets extension.  However, all TLS implementations of Snap
   Start SHOULD implement session tickets.  TLS clients which send a
   Snap Start extension SHOULD also send a Session Tickets extension.

Langley                 Expires December 20, 2010              [Page 13]

Internet-Draft               TLS Snap Start                    June 2010

9.  Interactions with OCSP stapling

   Clients attempting a Snap Start handshake MUST trust the server's
   cached certificate.  This includes validating revocation information
   (via OCSP [RFC2560], CRLs [RFC5280] etc) as the local policy

   TLS clients which send a Snap Start extension SHOULD NOT send a
   "status_request" extension as defined in RFC 4366 [RFC4366] section
   3.6.  A client may be able to predict the contents of a
   "CertificateStatus" message but, if it can predict it, then it
   doesn't need it and, if it needs fresh OCSP information, then it
   shouldn't have attempted a Snap Start handshake using a certificate
   that it cannot validate.

   This does preclude the case where the client has cached a valid OCSP
   response that is still timely, but the server has a response valid
   further into the future.  We can only suggest that opportunistic OCSP
   stapling additionally be included in application level protocols for
   this situation.

Langley                 Expires December 20, 2010              [Page 14]

Internet-Draft               TLS Snap Start                    June 2010

10.  Interactions with client certificates

   A Snap Start handshake can include client-side authentication.  In
   this case the client must predict that the server will send a
   "CertificateRequest" message, calculate its
   "predicted_server_handshake" accordingly and embed "Certificate" and
   "CertificateVerify" messages in the Snap Start extension.

   The "handshake_messages" over which the "CertificateVerify" is
   calculated MUST omit the Snap Start extension as detailed for the
   Finished calculation, above.

Langley                 Expires December 20, 2010              [Page 15]

Internet-Draft               TLS Snap Start                    June 2010

11.  Examples

   Firstly, a client contacting a previously unknown server for the
   first time may include an empty Snap Start extension in its
   ClientHello.  The server, if so capable, could reply with:

   01 02 03 04 05 06 07 08         (Orbit value)
   00 2f                           (Cipher suite)

   A future connection may now attempt a Snap Start by including a Snap
   Start extension in the ClientHello with the following contents:

   01 02 03 04 05 06 07 08         (Orbit value)
   88 c0 1e 1c a9 4e ...           (Random bytes)
   aa bb cc dd ee ff 00 11         (predicted server handshake)
   16 03 03 00 84 10 00 00 80 ...  (ClientKeyExchange)
   14 03 03 00 01 01               (ChangeCipherSpec)
   16 03 03 00 20 ...              (Finished)
   17 03 03 00 50 ...              (Application data)

   If the Snap Start is successful, then the message flow looks like

   ClientHello     -------->
                   <--------     Application data

   If the client mispredicts the server's handshake, however, then the
   flow is unaltered from Figure 1 in RFC 5246 section 7.3.

Langley                 Expires December 20, 2010              [Page 16]

Internet-Draft               TLS Snap Start                    June 2010

12.  Prior work

   The idea of cache-side caching of long lived server parameters has
   been discussed in Client Side Caching for TLS [fasttrack] and
   specified in draft-ietf-tls-cached-info [cached-info].  Client Side
   Caching for TLS [fasttrack] also considered including an
   opportunistic "ClientKeyExchange" message in the client's initial

Langley                 Expires December 20, 2010              [Page 17]

Internet-Draft               TLS Snap Start                    June 2010

13.  IANA Considerations

   This document requires IANA to update its registry of TLS extensions
   to assign an entry, referred herein as "snap_start".

Langley                 Expires December 20, 2010              [Page 18]

Internet-Draft               TLS Snap Start                    June 2010

14.  Acknowledgements

   This document benefited specifically from discussions with Wan-Teh
   Chang, Bodo Moeller and Nagendra Modadugu.

Langley                 Expires December 20, 2010              [Page 19]

Internet-Draft               TLS Snap Start                    June 2010

15.  Normative References

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

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

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

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

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [fnv1a]    Noll, L., "FNV hash".

              Santesson, S., "Transport Layer Security (TLS) Cached
              Information Extension", Internet Draft (work in progress),
              April 2010.

              Shacham, H., Boneh, D., and E. Rescorla, "Client Side
              Caching for TLS", Nov 2004.

Langley                 Expires December 20, 2010              [Page 20]

Internet-Draft               TLS Snap Start                    June 2010

Appendix A.  Changes

   To be removed by RFC Editor before publication

Langley                 Expires December 20, 2010              [Page 21]

Internet-Draft               TLS Snap Start                    June 2010

Author's Address

   Adam Langley
   Google Inc


Langley                 Expires December 20, 2010              [Page 22]