idnits 2.17.00 (12 Aug 2021) /tmp/idnits45889/draft-ietf-tls-session-hash-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 12, 2014) is 2746 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Bhargavan 3 Internet-Draft A. Delignat-Lavaud 4 Expires: May 16, 2015 A. Pironti 5 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 November 12, 2014 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-ietf-tls-session-hash-03 16 Abstract 18 The Transport Layer Security (TLS) master secret is not 19 cryptographically bound to important session parameters. 20 Consequently, it is possible for an active attacker to set up two 21 sessions, one with a client and another with a server, such that the 22 master secrets on the two sessions are the same. Thereafter, any 23 mechanism that relies on the master secret for authentication, 24 including session resumption, becomes vulnerable to a man-in-the- 25 middle attack, where the attacker can simply forward messages back 26 and forth between the client and server. This specification defines 27 a TLS extension that contextually binds the master secret to a log of 28 the full handshake that computes it, thus preventing such attacks. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 16, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5 67 4. The Extended Master Secret . . . . . . . . . . . . . . . . . 5 68 5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Extension Definition . . . . . . . . . . . . . . . . . . 6 70 5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 6.1. Triple Handshake Preconditions and Impact . . . . . . . . 6 73 6.2. Cryptographic Properties of the Hash Function . . . . . . 8 74 6.3. Session Hash Handshake Coverage . . . . . . . . . . . . . 8 75 6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 9.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 In TLS [RFC5246], every session has a "master_secret" computed as: 87 master_secret = PRF(pre_master_secret, "master secret", 88 ClientHello.random + ServerHello.random) 89 [0..47]; 91 where the "pre_master_secret" is the result of some key exchange 92 protocol. For example, when the handshake uses an RSA ciphersuite, 93 this value is generated uniformly at random by the client, whereas 94 for DHE ciphersuites, it is the result of a Diffie-Hellman key 95 agreement. 97 As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, 98 an active attacker can synchronize two TLS sessions so that they 99 share the same "master_secret". For an RSA key exchange where the 100 client is unauthenticated, this is achieved as follows. Suppose a 101 client, C, connects to a malicious server, A. A then connects to a 102 server, S, and completes both handshakes. For simplicity, assume 103 that C and S only use RSA ciphersuites. (Note that C thinks it is 104 connecting to A and is oblivious of S's involvement.) 106 1. C sends a "ClientHello" to A, and A forwards it to S. 108 2. S sends a "ServerHello" to A, and A forwards it to C. 110 3. S sends a "Certificate", containing its certificate chain, to A. 111 A replaces it with its own certificate chain and sends it to C. 113 4. S sends a "ServerHelloDone" to A, and A forwards it to C. 115 5. C sends a "ClientKeyExchange" to A, containing the 116 "pre_master_secret", encrypted with A's public key. A decrypts 117 the "pre_master_secret", re-encrypts it with S's public key and 118 sends it on to S. 120 6. C sends a "Finished" to A. A computes a "Finished" for its 121 connection with S, and sends it to S. 123 7. S sends a "Finished" to A. A computes a "Finished" for its 124 connection with C, and sends it to C. 126 At this point, both connections (between C and A, and between A and 127 S) have new sessions that share the same "pre_master_secret", 128 "ClientHello.random", "ServerHello.random", as well as other session 129 parameters, including the session identifier and, optionally, the 130 session ticket. Hence, the "master_secret" value will be equal for 131 the two sessions and it will be associated both at C and S with the 132 same session ID, even though the server identities on the two 133 connections are different. Moreover, the record keys on the two 134 connections will also be the same. 136 Similar scenarios can be achieved when the handshake uses a DHE 137 ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit 138 curve. Even if the client or server does not prefer using RSA or 139 DHE, the attacker can force them to use it by offering only RSA or 140 DHE in its hello messages. Other key exchanges may also be 141 vulnerable. If client authentication is used, the attack still 142 works, except that the two sessions now differ on both client and 143 server identities. 145 Once A has synchronized the two connections, since the keys are the 146 same on the two sides, it can step away and transparently forward 147 messages between C and S, reading and modifying when it desires. In 148 the key exchange literature, such occurrences are called unknown key- 149 share attacks, since C and S share a secret but they both think that 150 their secret is shared only with A. In themselves, these attacks do 151 not break integrity or confidentiality between honest parties, but 152 they offer a useful starting point from which to mount impersonation 153 attacks on C and S. 155 Suppose C tries to resume its session on a new connection with A. A 156 can then resume its session with S on a new connection and forward 157 the abbreviated handshake messages unchanged between C and S. Since 158 the abbreviated handshake only relies on the master secret for 159 authentication, and does not mention client or server identities, 160 both handshakes complete successfully, resulting in the same session 161 keys and the same handshake log. A still knows the connection keys 162 and can send messages to both C and S. 164 Critically, on the new connection, even the handshake log is the same 165 on C and S, thus defeating any man-in-the-middle protection scheme 166 that relies on the uniqueness of finished messages, such as the 167 secure renegotiation indication extension [RFC5746] or TLS channel 168 bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on 169 such session synchronization attacks. In particular, it describes a 170 man-in-the-middle attack that circumvents the protections of 171 [RFC5746] to break client-authenticated TLS renegotiation after 172 session resumption. Similar attacks apply to application-level 173 authentication mechanisms that rely on channel bindings [RFC5929] or 174 on key material exported from TLS [RFC5705]. 176 The underlying protocol issue is that since the master secret is not 177 guaranteed to be unique across sessions, it cannot be used on its own 178 as an authentication credential. This specification introduces a TLS 179 extension that computes the "master_secret" value from the log of the 180 handshake that computes it, so that different handshakes will, by 181 construction, create different master secrets. 183 2. Requirements Notation 185 This document uses the same notation and terminology used in the TLS 186 Protocol specification [RFC5246]. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 3. The TLS Session Hash 194 When a full TLS handshake takes place, we define 196 session_hash = Hash(handshake_messages) 198 where "handshake_messages" refers to all handshake messages sent or 199 received, starting at the ClientHello up to and including the 200 ClientKeyExchange message, including the type and length fields of 201 the handshake messages. This is the concatenation of all the 202 exchanged Handshake structures, as defined in Section 7.4 of 203 [RFC5246]. 205 For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 206 of [RFC5246] for the Finished message computation. For all previous 207 versions of TLS, the "Hash" function computes the concatenation of 208 MD5 and SHA1. 210 There is no "session_hash" for resumed handshakes, as they do not 211 lead to the creation of a new session. 213 4. The Extended Master Secret 215 When the extended master secret extension is negotiated in a TLS 216 session, the "master_secret" is computed as 218 master_secret = PRF(pre_master_secret, "extended master secret", 219 session_hash) 220 [0..47]; 222 The extended master secret computation differs from the [RFC5246] in 223 the following ways: 225 o The "extended master secret" label is used instead of "master 226 secret"; 228 o The "session_hash" is used instead of the "ClientHello.random" and 229 "ServerHello.random". 231 The "session_hash" depends upon a handshake log that includes 232 "ClientHello.random" and "ServerHello.random", in addition to 233 ciphersuites, key exchange information and client and server 234 certificates. Consequently, the extended master secret depends upon 235 the choice of all these session parameters. 237 This design reflects the recommendation that keys should be bound to 238 the security contexts that compute them [sp800-108]. The technique 239 of mixing a hash of the key exchange messages into master key 240 derivation is already used in other well-known protocols such as SSH 241 [RFC4251]. 243 Clients and servers SHOULD NOT resume sessions that do not use the 244 extended master secret, especially if they rely on features like 245 compound authentication that fall into the vulnerable cases described 246 in Section 6.1. 248 5. Extension Negotiation 250 5.1. Extension Definition 252 This document defines a new TLS extension, "extended_master_secret" 253 (with extension type 0x0017), which is used to signal both client and 254 server to use the extended master secret computation. The 255 "extension_data" field of this extension is empty. Thus, the entire 256 encoding of the extension is 00 17 00 00. 258 If client and server agree on this extension and a full handshake 259 takes place, both client and server MUST use the extended master 260 secret derivation algorithm, as defined in Section 4. 262 If an abbreviated handshake takes place, the extension has no effect. 263 The resumed session is protected by the extended master secret if the 264 extension was negotiated in the full handshake that generated the 265 session. 267 5.2. Client and Server Behavior 269 In its ClientHello message, a client implementing this document MUST 270 send the "extended_master_secret" extension. 272 If a server implementing this document receives the 273 "extended_master_secret" extension, it MUST include the 274 "extended_master_secret" extension in its ServerHello message. 276 6. Security Considerations 278 6.1. Triple Handshake Preconditions and Impact 280 One way to mount a triple handshake attack has been described in 281 Section 1, along with a mention of the security mechanisms that break 282 due to the attack; more in-depth discussion and diagrams can be found 283 in [TRIPLE-HS]. Here, some further discussion is presented about 284 attack preconditions and impact. 286 To mount a triple handshake attack, it must be possible to force the 287 same master secret on two different sessions. For this to happen, 288 two preconditions must be met: 290 o The client, C, must be willing to connect to a malicious server, 291 A. In certain contexts, like the web, this can be easily 292 achieved, since a browser can be instructed to load content from 293 an untrusted origin. 295 o The pre-master secret must be synchronized on the two sessions. 296 This is particularly easy to achieve with the RSA key exchange, 297 but arbitrary DH groups or ECDH curves can be exploited to this 298 effect as well. 300 Once the master secret is synchronized on two sessions, any security 301 property that relies on the uniqueness of the master secret is 302 compromised. For example, a TLS exporter [RFC5705] no longer 303 provides a unique key bound to the current session. 305 TLS session resumption also relies on the uniqueness of the master 306 secret to authenticate the resuming peers. Hence, if a synchronized 307 session is resumed, the peers cannot be sure about each other 308 identity, and the attacker knows the connection keys. Clearly, a 309 precondition to this step of the attack is that both client and 310 server support session resumption (either via session identifier or 311 session tickets [RFC5077]). 313 Additionally, in a synchronized abbreviated handshake, the whole 314 transcript is synchronized, which includes the "verify_data" values. 315 So, after an abbreviated handshake, channel bindings like "tls- 316 unique" [RFC5929] will not identify uniquely the connection anymore. 318 Synchronization of the "verify_data" in abbreviated handshakes also 319 undermines the security guarantees of the renegotiation indication 320 extension [RFC5746], re-enabling a prefix-injection flaw similar to 321 the renegotiation attack [Ray09]. However, in a triple handshake 322 attack, the client sees the server certificate changing across 323 different full handshakes. Hence, a precondition to mount this stage 324 of the attack is that the client accepts different certificates at 325 each handshake, even if their common names do not match. Before the 326 triple handshake attack was discovered, this used to be widespread 327 behavior, at least among some web browsers, that where hence 328 vulnerable to the attack. 330 The extended master secret extension thwarts triple handshake attacks 331 at their first stage, by ensuring that different sessions necessarily 332 end up with different master secret values. Hence, all security 333 properties relying on the uniqueness of the master secret are now 334 expected to hold. In particular, if a TLS session is protected by 335 the extended master secret extension, it is safe to resume it, to use 336 its channel bindings, and to allow for certificate changes across 337 renegotiation, meaning that all certificates are controlled by the 338 same peer. 340 6.2. Cryptographic Properties of the Hash Function 342 The session hashes of two different sessions need to be distinct, 343 hence the "Hash" function used to compute the "session_hash" needs to 344 be collision resistant. As such, hash functions such as MD5 or SHA1 345 are NOT RECOMMENDED. 347 We observe that the "Hash" function used in the Finished message 348 computation already needs to be collision resistant, for the 349 renegotiation indication extension [RFC5746] to work: a collision on 350 the verify_data (and hence on the hash function computing the 351 handshake messages hash) defeats the renegotiation indication 352 countermeasure. 354 As a matter of fact, all current ciphersuites defined for TLS 1.2 use 355 SHA256 or better. For earlier versions of the protocol, only MD5 and 356 SHA1 can be assumed to be supported, and this document does not 357 require legacy implementations to add support for new hash functions. 359 6.3. Session Hash Handshake Coverage 361 The "session_hash" is designed to encompass all relevant session 362 information, including ciphersuite negotiation, key exchange messages 363 and client and server identities. 365 This document sets the "session_hash" to cover all handshake messages 366 up to and including the ClientKeyExchange. In this way, on one hand, 367 all the relevant session information is included; on the other hand, 368 the master secret can be computed right after the ClientKeyExchange 369 message, allowing implementations to shred the pre-master secret from 370 memory as soon as possible. 372 It is crucial that any message sent after the ClientKeyExchange does 373 not alter the session information. This is the case for the Finished 374 messages, as well as for the client CertificateVerify in client- 375 authenticated sessions. This also applies to session ticket messages 376 [RFC5077]. Any protocol extension that adds protocol messages after 377 the Client Key Exchange MUST either ensure that such messages do not 378 alter the session information, or it MUST analyze the impact of the 379 protocol changes with respect to the handshake coverage of the 380 session hash. 382 6.4. No SSL 3.0 Support 384 SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is 385 equally vulnerable to the triple handshake attacks. 387 The use of extensions precludes use of the extended master secret 388 with SSL 3.0. Yet, this protocol uses encryption schemes and 389 algorithms that are now considered weak. Furthermore, it seems 390 likely that any system that did not upgrate from SSL 3.0 to any later 391 version of TLS will be exposed to several other vulnerabilties 392 anyway. As a consequence, this document does not provide workarounds 393 to accommodate SSL 3.0. 395 7. IANA Considerations 397 IANA has added the extension code point 23 (0x0017), which has been 398 used for prototype implementations, for the "extended_master_secret" 399 extension to the TLS ExtensionType values registry as specified in 400 TLS [RFC5246]. 402 8. Acknowledgments 404 The triple handshake attacks were originally discovered by Antoine 405 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 406 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 407 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 408 ideas in this draft emerged from discussions with Martin Abadi, Ben 409 Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric 410 Rescorla, Martin Rex, Brian Smith. 412 9. References 414 9.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 420 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 422 9.2. Informative References 424 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 425 "Transport Layer Security (TLS) Renegotiation Indication 426 Extension", RFC 5746, February 2010. 428 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 429 Layer Security (TLS)", RFC 5705, March 2010. 431 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 432 for TLS", RFC 5929, July 2010. 434 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 435 Protocol Architecture", RFC 4251, January 2006. 437 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 438 "Transport Layer Security (TLS) Session Resumption without 439 Server-Side State", RFC 5077, January 2008. 441 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 442 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 443 August 2011. 445 [TRIPLE-HS] 446 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 447 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 448 Breaking and Fixing Authentication over TLS", IEEE 449 Symposium on Security and Privacy, pages 98-113 , 2014. 451 [sp800-108] 452 Chen, L., "NIST Special Publication 800-108: 453 Recommendation for Key Derivation Using Pseudorandom 454 Functions", Unpublished draft , 2009. 456 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 458 Authors' Addresses 460 Karthikeyan Bhargavan 461 Inria Paris-Rocquencourt 462 23, Avenue d'Italie 463 Paris 75214 CEDEX 13 464 France 466 Email: karthikeyan.bhargavan@inria.fr 468 Antoine Delignat-Lavaud 469 Inria Paris-Rocquencourt 470 23, Avenue d'Italie 471 Paris 75214 CEDEX 13 472 France 474 Email: antoine.delignat-lavaud@inria.fr 475 Alfredo Pironti 476 Inria Paris-Rocquencourt 477 23, Avenue d'Italie 478 Paris 75214 CEDEX 13 479 France 481 Email: alfredo.pironti@inria.fr 483 Adam Langley 484 Google Inc. 485 1600 Amphitheatre Parkway 486 Mountain View, CA 94043 487 USA 489 Email: agl@google.com 491 Marsh Ray 492 Microsoft Corp. 493 1 Microsoft Way 494 Redmond, WA 98052 495 USA 497 Email: maray@microsoft.com