Network Working Group A. Langley Internet-Draft Google Inc Expires: December 20, 2010 June 18, 2010 Transport Layer Security (TLS) Snap Start draft-agl-tls-snapstart-00 Abstract 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 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 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 (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. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 handshake. 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 dictates. 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 this: ClientHello --------> ChangeCipherSpec Finished <-------- 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 flow. 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". [cached-info] Santesson, S., "Transport Layer Security (TLS) Cached Information Extension", Internet Draft (work in progress), April 2010. [fasttrack] 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 Email: agl@google.com Langley Expires December 20, 2010 [Page 22]