idnits 2.17.1 draft-agl-tls-snapstart-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2010) is 5060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 217 -- Looks like a reference, but probably isn't: '20' on line 216 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Langley 3 Internet-Draft Google Inc 4 Expires: December 20, 2010 June 18, 2010 6 Transport Layer Security (TLS) Snap Start 7 draft-agl-tls-snapstart-00 9 Abstract 11 This document describes a Transport Layer Security (TLS) extension 12 for eliminating the latency of handshakes when the client has prior 13 knowledge about the server. Unlike resumption, this prior knowledge 14 is not secret and may be obtained from third parties and stored on 15 disk for significant periods of time. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 20, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 55 5. Snap Start Extension . . . . . . . . . . . . . . . . . . . . . 8 56 6. Active attack considerations . . . . . . . . . . . . . . . . . 11 57 7. Requirements on the application . . . . . . . . . . . . . . . 12 58 8. Interactions with the Session Tickets extension . . . . . . . 13 59 9. Interactions with OCSP stapling . . . . . . . . . . . . . . . 14 60 10. Interactions with client certificates . . . . . . . . . . . . 15 61 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 62 12. Prior work . . . . . . . . . . . . . . . . . . . . . . . . . . 17 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 64 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 65 15. Normative References . . . . . . . . . . . . . . . . . . . . . 20 66 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 21 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 1. Introduction 71 Snap Start aims to remove the latency overhead of TLS handshakes in 72 the case that the application protocol involves the client speaking 73 first. Currently, TLS handshaking imposes additional latency and is 74 costly for time-sensitive applications. 76 In order to achieve this, the initial flow from the client must 77 contain application data and, therefore, everything needed for the 78 server to complete a handshake and process it. Starting from this 79 premise we can derive the essential features of Snap Start. 81 2. Design 83 At first we are only considering the case of a full handshake. 84 Assume, for the sake of argument, a client that is capable of 85 predicting the contents of a server's first handshake flow (i.e. the 86 "ServerHello" message through to the "ServerHelloDone"). Such a 87 client could send "ClientKeyExchange", "ChangeCipherSpec" and 88 "Finished" messages immediately following its "ClientHello". It 89 would then be able to transmit application data records and we have 90 successfully eliminated the TLS handshake latency. 92 However, several elements of the server's first handshake flow are 93 unpredictable. Fundamentally, any ephemeral Diffie-Hellman based 94 cipher suite is incompatible with Snap Start so the following assumes 95 that the server is using non-ephemeral key agreement. 97 The chosen cipher suite, compression method, supported extensions, 98 ordering of those extensions, certificate etc are all somewhat 99 unpredictable for a given server but are highly correlated across 100 time. Given a previous handshake with the same server, assuming that 101 it will make the same choices when presented with a similar 102 "ClientHello" is sufficiently accurate to expect a very high rate of 103 prediction of these elements of the handshake. 105 The server's chosen session id is unpredictable. However, this can 106 be eliminated by using Session Tickets [RFC5077]. When Session 107 Tickets are in use the "ServerHello" doesn't include a session id and 108 the "NewSessionTicket" message itself is not part of the first flow. 110 Lastly, the "server_random" is unpredictable. The "server_random" 111 exists to provide uniqueness and freshness. When the server picks a 112 random value it can be assured that no previous TLS connection has 113 ever used the same value. Therefore the connection cannot be a 114 replay of the client's traffic. Additionally, the server knows when 115 its unpredictable random value was created, relative to its local 116 clock, and therefore knows that handshake hasn't been delayed for an 117 arbitrary amount of time. 119 In order for the "server_random" to be predictable by the client, it 120 will have to be chosen by the client and suggested to the server. In 121 order for the server to be assured of uniqueness, it will have to 122 remember every "server_random" value that has been used so that it 123 may reject duplicates. (Several methods of limiting the amount of 124 state required for this are introduced below.) 126 Even without Snap Start, an attacker can delay an application data 127 record in an established connection. However, both parties to the 128 connection are likely to timeout after some period of inactivity, 129 bounding the amount of possible delay introduced. With Snap Start, 130 since we are assuming that the client's initial flow includes a full 131 handshake and application data, an attacker could arbitrarily delay 132 the flow and have the server process the application data at a time 133 of their choosing. As the server lacks an nonce it has no way of 134 detecting this. 136 Without a similar mechanism to bound the delay of a Snap Start 137 handshake, an attacker could perform a pseudo-replay attack: a 138 handshake is delayed until the client retries, but the first 139 handshake can still be used to deliver the same application data a 140 second time. Because of this (and for other reasons other reasons 141 given below) we require some degree of clock synchronisation between 142 the client and server with respect the the timestamp in the 143 "ClientHello". The level of synchronisation required is left to the 144 application layer to determine although it's recommended that the 145 permitted clock skew be shorter than the application's retry timeout. 147 3. Details 149 The essential features of Snap Start are now established: the client 150 predicts the server's handshake flow using a client suggested 151 "server_random", SessionTickets and knowledge from a previous 152 connection to the same server. 154 We now note that this functions for both full and abbreviated 155 handshakes. The abbreviated handshake retains its lower 156 computational requirements but both now complete in the same number 157 of round trips. 159 In order to limit the amount of state required for the server to 160 reject repeated "server_random"s, we allow the server to bound this 161 state temporally and spatially. In the temporal dimension, we define 162 that the "gmt_unix_time" of the server random is taken from 163 "gmt_unix_time" of the client's random value. The server may use 164 this timestamp to reject all suggested random values outside some 165 window around the current time. 167 Spatially, we define that the subsequent eight bytes of the server's 168 random value are the server's 'orbit' value. This value must be 169 discovered by the client from a previous (non Snap Start) handshake. 170 In the event that several, geographically separated servers share the 171 same certificates, they may use different orbit values. This allows 172 one to reject "server_random" values for the other without any 173 communication between them. (The term 'orbit' was chosen only to be 174 short and otherwise reasonably meaningless in this context.) 176 4. Requirements Notation 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 5. Snap Start Extension 184 A new extension type ("snap_start(TBD)") is defined and MAY be 185 included by the client in its "ClientHello" message. If, and only 186 if, the server sees this extension in the "ClientHello", it MAY 187 choose to include the extension in its "ServerHello". 189 enum { 190 snap_start(TBD), (65535) 191 } ExtensionType; 193 The "extension_data" field of a "snap_start" extension in a 194 "ClientHello" MAY be empty. 196 If the server chooses to echo a "snap_start" extension then it is 197 indicating that it MAY support Snap Start on future connections. The 198 contents of the "extension_data" in this case MUST be: 200 struct { 201 opaque orbit[8]; 202 CipherSuite snap_start_cipher_suite; 203 } ServerSnapStart; 205 "orbit" is the server's current orbit value and 206 "snap_start_cipher_suite" contains the CipherSuite value that the 207 client should assume that the server will use in a Snap Start 208 handshake. 210 If the client wishes to attempt a Snap Start connection then it 211 includes a non-empty "snap_start" extension in its "ClientHello". If 212 the extension is not empty, then its contents MUST be: 214 struct { 215 opaque orbit[8]; 216 opaque random_bytes[20]; 217 opaque predicted_server_handshake[8]; 218 // TLSCiphertext structures follow 219 } ClientSnapStart; 221 Following this, without a length prefix, the client may include one 222 or more "TLSCiphertext" structures to be processed by the server in 223 the case that the Snap Start is successful. These records are as 224 described in RFC 5246 [RFC5246] section 6.2 226 The "orbit" MUST contain an orbit value obtained from a previous 227 connection to the same server. "random_bytes" MUST contain 20 random 228 bytes from a cryptographic random source equal in strength to the one 229 used for the "client_random". 231 "predicted_server_handshake" MUST contain an FNV1a64 [fnv1a] hash of 232 the server's predicted response flow. This hash is taken over the 233 bytes of the "Handshake" structures, as defined in RFC 5246 section 234 7.4. If the client is attempting to resume a connection then this is 235 calculated over the server's "ServerHello" message. Otherwise, this 236 is calculated over all handshake messages from the "ServerHello" to 237 the "ServerHelloDone" (inclusive). The client's prediction MUST 238 assume that the server chooses its server random as detailed below. 239 The client's prediction MUST also assume that the server includes a 240 Snap Start extension with the same "ServerSnapStart" contents as 241 previously observed. 243 If the client's prediction is correct then the server MAY perform a 244 Snap Start handshake. If the server wishes to perform a Snap Start 245 handshake then it MUST form its "random" value from the 246 "gmt_unix_time" of the client's "random", followed by the server's 247 orbit value, followed by the contents of "random_bytes" from the 248 client's Snap Start extension. 250 The server MUST NOT transmit any predicted handshake messages and 251 MUST start processing records from the client's Snap Start extension. 252 For the purposes of the Finished calculation, the client's 253 "ClientHello" is hashed as if the "snap_start" extension were not 254 included (the "length" field of the "Handshake" structure from RFC 255 5246 section 7.4, and the prefixed length of the "extensions" member 256 of the "ClientHello" are updated accordingly). When processing 257 records from the extension, they are hashed as usual. Once the set 258 of records embedded in the "ClientHello" has been exhausted, the 259 server resumes reading records from the network. Records must not be 260 partially contained within the "ClientHello" and partially read from 261 the network. 263 (Since the "ClientHello" is likely to have a "Finished" message 264 embedded within it, it cannot be hashed into the Finished calculation 265 as normal as its contents would then depend in its own hash. One 266 could consider hashing with the embedded hash zeroed out, however a 267 "Finished" message is encrypted under the negotiated cipher suite and 268 a CBC-based ciphersuite would spread the effects of the embedded hash 269 beyond its apparent boundaries. Likewise, the "Finished" message is 270 compressed using the negotiated compression algorithm thus the length 271 of the record, and thus the extension, depend on the contents of the 272 hash. Given these limitations, removing the extension altogether is 273 the simplest way to break the cycle.) 275 If the server chooses not to perform a Snap Start handshake (for any 276 reason, including that the application rejected the suggested random 277 value or that the client mispredicted the handshake) then the 278 handshake MUST continue as normal. The server MUST NOT change the 279 way that it hashes the "ClientHello". The server MAY echo a 280 "snap_start" extension. 282 6. Active attack considerations 284 Given that this draft makes changes to the Finished hash, it's 285 required to show that no active attack can cause a handshake to 286 complete which differs from that which would have occurred otherwise. 288 Since the "snap_start" extension is not included in the Finished hash 289 of a Snap Start handshake, we have to consider the results of an 290 attacker manipulating its contents. 292 Firstly, since the embedded records are hashed as usual, the same 293 security properties hold: any manipulation will be detected by the 294 Finished hash, or by a MAC verification failure. 296 An attacker could manipulate the orbit. This would typically cause 297 the server to reject the suggested random value and a normal 298 handshake would detect the manipulation. In the case that the server 299 still proceeds with a Snap Start handshake, the orbit is copied into 300 the "server_random" in the "ServerHello", which is then hashed into 301 the Finished calculation (although not transmitted). 303 An attacker could manipulate the suggested server random. The same 304 argument as for the orbit holds here. 306 An attacker could manipulate the hash of the predicted messages. 307 Assuming that the client correctly predicted the hash, the 308 manipulation would cause the server to not perform a Snap Start 309 handshake and the manipulation would be detected. Assuming that the 310 client mispredicted, and that the manipulation results in a 311 different, but also incorrect, value then the same argument applies. 312 Assuming that the client mispredicted and the manipulation corrects 313 the hash, the server could perform a Snap Start handshake, but the 314 differing contents of the predicted handshake messages will be hashed 315 into the Finished calculation and the manipulation will be detected. 317 7. Requirements on the application 319 Applications are required to ensure that no suggested random value is 320 accepted twice within the scope of any given certificate. In 321 general, validation of the suggested random value is outside the 322 scope a TLS implementation (although it may handle simple cases and 323 provide utility code for others). Applications may use the orbit 324 value and client timestamp to aid them in this. Applications may 325 always safely reject a suggested random value. Applications SHOULD 326 limit the allowed difference between the timestamp in the suggested 327 random value and the current time in order to prevent arbitrary 328 delays, as detailed in the design section of this document. 330 For a single server deployment, the server may generate a new, random 331 orbit value each time that it starts and, thereafter, maintain an in- 332 memory data structure. Each random value seen should be "struck off" 333 by recording it in this data structure (the "strike register"). The 334 strike register's size can be bound by fixed limits and by rejecting 335 all random values where the timestamp is outside a certain window 336 around the current time. 338 For a multi-server deployment in a single location, the servers 339 should share an orbit value and a strike register. The strike 340 register is likely to be a held in a single location which the TLS 341 servers access over an internal network. 343 For a multi-cluster deployment, where the clusters are geographically 344 separated, each cluster should have its own orbit value and shared 345 strike register. The effectiveness of Snap Start in this setup is 346 limited by the probability of a given client repeatedly being served 347 by the same cluster. With pure round robin scheduling, a Snap Start 348 handshake is unlikely to be successful. 350 8. Interactions with the Session Tickets extension 352 A successful Snap Start abbreviated handshake can occur without the 353 use of session tickets. A successful Snap Start full handshake, 354 without session tickets, can only occur if the server doesn't 355 generate a random session id. A server MAY choose not to generate a 356 session id if the client presents a Snap Start extension but not a 357 session tickets extension. However, all TLS implementations of Snap 358 Start SHOULD implement session tickets. TLS clients which send a 359 Snap Start extension SHOULD also send a Session Tickets extension. 361 9. Interactions with OCSP stapling 363 Clients attempting a Snap Start handshake MUST trust the server's 364 cached certificate. This includes validating revocation information 365 (via OCSP [RFC2560], CRLs [RFC5280] etc) as the local policy 366 dictates. 368 TLS clients which send a Snap Start extension SHOULD NOT send a 369 "status_request" extension as defined in RFC 4366 [RFC4366] section 370 3.6. A client may be able to predict the contents of a 371 "CertificateStatus" message but, if it can predict it, then it 372 doesn't need it and, if it needs fresh OCSP information, then it 373 shouldn't have attempted a Snap Start handshake using a certificate 374 that it cannot validate. 376 This does preclude the case where the client has cached a valid OCSP 377 response that is still timely, but the server has a response valid 378 further into the future. We can only suggest that opportunistic OCSP 379 stapling additionally be included in application level protocols for 380 this situation. 382 10. Interactions with client certificates 384 A Snap Start handshake can include client-side authentication. In 385 this case the client must predict that the server will send a 386 "CertificateRequest" message, calculate its 387 "predicted_server_handshake" accordingly and embed "Certificate" and 388 "CertificateVerify" messages in the Snap Start extension. 390 The "handshake_messages" over which the "CertificateVerify" is 391 calculated MUST omit the Snap Start extension as detailed for the 392 Finished calculation, above. 394 11. Examples 396 Firstly, a client contacting a previously unknown server for the 397 first time may include an empty Snap Start extension in its 398 ClientHello. The server, if so capable, could reply with: 400 01 02 03 04 05 06 07 08 (Orbit value) 401 00 2f (Cipher suite) 403 A future connection may now attempt a Snap Start by including a Snap 404 Start extension in the ClientHello with the following contents: 406 01 02 03 04 05 06 07 08 (Orbit value) 407 88 c0 1e 1c a9 4e ... (Random bytes) 408 aa bb cc dd ee ff 00 11 (predicted server handshake) 409 16 03 03 00 84 10 00 00 80 ... (ClientKeyExchange) 410 14 03 03 00 01 01 (ChangeCipherSpec) 411 16 03 03 00 20 ... (Finished) 412 17 03 03 00 50 ... (Application data) 414 If the Snap Start is successful, then the message flow looks like 415 this: 417 ClientHello --------> 418 ChangeCipherSpec 419 Finished 420 <-------- Application data 422 If the client mispredicts the server's handshake, however, then the 423 flow is unaltered from Figure 1 in RFC 5246 section 7.3. 425 12. Prior work 427 The idea of cache-side caching of long lived server parameters has 428 been discussed in Client Side Caching for TLS [fasttrack] and 429 specified in draft-ietf-tls-cached-info [cached-info]. Client Side 430 Caching for TLS [fasttrack] also considered including an 431 opportunistic "ClientKeyExchange" message in the client's initial 432 flow. 434 13. IANA Considerations 436 This document requires IANA to update its registry of TLS extensions 437 to assign an entry, referred herein as "snap_start". 439 14. Acknowledgements 441 This document benefited specifically from discussions with Wan-Teh 442 Chang, Bodo Moeller and Nagendra Modadugu. 444 15. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 450 Adams, "X.509 Internet Public Key Infrastructure Online 451 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 453 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 454 and T. Wright, "Transport Layer Security (TLS) 455 Extensions", RFC 4366, April 2006. 457 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 458 "Transport Layer Security (TLS) Session Resumption without 459 Server-Side State", RFC 5077, January 2008. 461 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 462 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 464 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 465 Housley, R., and W. Polk, "Internet X.509 Public Key 466 Infrastructure Certificate and Certificate Revocation List 467 (CRL) Profile", RFC 5280, May 2008. 469 [fnv1a] Noll, L., "FNV hash". 471 [cached-info] 472 Santesson, S., "Transport Layer Security (TLS) Cached 473 Information Extension", Internet Draft (work in progress), 474 April 2010. 476 [fasttrack] 477 Shacham, H., Boneh, D., and E. Rescorla, "Client Side 478 Caching for TLS", Nov 2004. 480 Appendix A. Changes 482 To be removed by RFC Editor before publication 484 Author's Address 486 Adam Langley 487 Google Inc 489 Email: agl@google.com