idnits 2.17.1 draft-ietf-tls-session-hash-04.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 (March 9, 2015) is 3335 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: September 10, 2015 A. Pironti 5 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 March 9, 2015 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-ietf-tls-session-hash-04 16 Abstract 18 The Transport Layer Security (TLS) master secret is not 19 cryptographically bound to important session parameters such as the 20 server certificate. Consequently, it is possible for an active 21 attacker to set up two sessions, one with a client and another with a 22 server, such that the master secrets on the two sessions are the 23 same. Thereafter, any mechanism that relies on the master secret for 24 authentication, including session resumption, becomes vulnerable to a 25 man-in-the-middle attack, where the attacker can simply forward 26 messages back and forth between the client and server. This 27 specification defines a TLS extension that contextually binds the 28 master secret to a log of the full handshake that computes it, thus 29 preventing such attacks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 67 3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5 68 4. The Extended Master Secret . . . . . . . . . . . . . . . . . 5 69 5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Extension Definition . . . . . . . . . . . . . . . . . . 6 71 5.2. Client and Server Behavior: Full Handshake . . . . . . . 6 72 5.3. Client and Server Behavior: Abbreviated Handshake . . . . 7 73 5.4. Interoperability Considerations . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6.1. Triple Handshake Preconditions and Impact . . . . . . . . 9 76 6.2. Cryptographic Properties of the Hash Function . . . . . . 10 77 6.3. Handshake Messages included in the Session Hash . . . . . 10 78 6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 In TLS [RFC5246], every session has a "master_secret" computed as: 90 master_secret = PRF(pre_master_secret, "master secret", 91 ClientHello.random + ServerHello.random) 92 [0..47]; 94 where the "pre_master_secret" is the result of some key exchange 95 protocol. For example, when the handshake uses an RSA ciphersuite, 96 this value is generated uniformly at random by the client, whereas 97 for DHE ciphersuites, it is the result of a Diffie-Hellman key 98 agreement. 100 As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, 101 an active attacker can synchronize two TLS sessions so that they 102 share the same "master_secret". For an RSA key exchange where the 103 client is unauthenticated, this is achieved as follows. Suppose a 104 client C connects to a server A. C does not realize that A is 105 malicious and that A connects in the background to an honest server S 106 and completes both handshakes. For simplicity, assume that C and S 107 only use RSA ciphersuites. 109 1. C sends a "ClientHello" to A, and A forwards it to S. 111 2. S sends a "ServerHello" to A, and A forwards it to C. 113 3. S sends a "Certificate", containing its certificate chain, to A. 114 A replaces it with its own certificate chain and sends it to C. 116 4. S sends a "ServerHelloDone" to A, and A forwards it to C. 118 5. C sends a "ClientKeyExchange" to A, containing the 119 "pre_master_secret", encrypted with A's public key. A decrypts 120 the "pre_master_secret", re-encrypts it with S's public key and 121 sends it on to S. 123 6. C sends a "Finished" to A. A computes a "Finished" for its 124 connection with S, and sends it to S. 126 7. S sends a "Finished" to A. A computes a "Finished" for its 127 connection with C, and sends it to C. 129 At this point, both connections (between C and A, and between A and 130 S) have new sessions that share the same "pre_master_secret", 131 "ClientHello.random", "ServerHello.random", as well as other session 132 parameters, including the session identifier and, optionally, the 133 session ticket. Hence, the "master_secret" value will be equal for 134 the two sessions and it will be associated both at C and S with the 135 same session ID, even though the server identities on the two 136 connections are different. Recall that C only sees A's certificate 137 and is unaware of A's connection with S. Moreover, the record keys on 138 the two connections will also be the same. 140 The above scenario shows that TLS does not guarantee that the master 141 secrets and keys used on different connections will be different. 142 Even if client authentication is used, the scenario still works, 143 except that the two sessions now differ on both client and server 144 identities. 146 A similar scenario can be achieved when the handshake uses a DHE 147 ciphersuite. Note that even if the client or server does not prefer 148 using RSA or DHE, the attacker can force them to use it by offering 149 only RSA or DHE in its hello messages. Handshakes using ECDHE 150 ciphersuites are also vulnerable if they allow arbitrary explicit 151 curves or use curves with small subgroups. Against more powerful 152 adversaries, other key exchanges, such as SRP and PSK, have also been 153 shown to be vulnerable [VERIFIED-BINDING]. 155 Once A has synchronized the two connections, since the keys are the 156 same on the two sides, it can step away and transparently forward 157 messages between C and S, reading and modifying when it desires. In 158 the key exchange literature, such occurrences are called unknown key- 159 share attacks, since C and S share a secret but they both think that 160 their secret is shared only with A. In themselves, these attacks do 161 not break integrity or confidentiality between honest parties, but 162 they offer a useful starting point from which to mount impersonation 163 attacks on C and S. 165 Suppose C tries to resume its session on a new connection with A. A 166 can then resume its session with S on a new connection and forward 167 the abbreviated handshake messages unchanged between C and S. Since 168 the abbreviated handshake only relies on the master secret for 169 authentication, and does not mention client or server identities, 170 both handshakes complete successfully, resulting in the same session 171 keys and the same handshake log. A still knows the connection keys 172 and can send messages to both C and S. 174 Critically, on the new connection, even the handshake log is the same 175 on C and S, thus defeating any man-in-the-middle protection scheme 176 that relies on the uniqueness of finished messages, such as the 177 secure renegotiation indication extension [RFC5746] or TLS channel 178 bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on 179 such session synchronization attacks. In particular, it describes a 180 man-in-the-middle attack that circumvents the protections of 181 [RFC5746] to break client-authenticated TLS renegotiation after 182 session resumption. Similar attacks apply to application-level 183 authentication mechanisms that rely on channel bindings [RFC5929] or 184 on key material exported from TLS [RFC5705]. 186 The underlying protocol issue leading to these attacks is that the 187 TLS master secret is not guaranteed to be unique across sessions, 188 since it is not context-bound to the full handshake that generated 189 it. If we fix this problem in the initial master secret computation, 190 all these attacks can be prevented. This specification introduces a 191 TLS extension that changes the way the "master_secret" value is 192 computed in a full handshake by including the log of the handshake 193 messages, so that different sessions will, by construction, have 194 different master secrets. 196 2. Requirements Notation 198 This document uses the same notation and terminology used in the TLS 199 Protocol specification [RFC5246]. 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 3. The TLS Session Hash 207 When a full TLS handshake takes place, we define 209 session_hash = Hash(handshake_messages) 211 where "handshake_messages" refers to all handshake messages sent or 212 received, starting at the ClientHello up to and including the 213 ClientKeyExchange message, including the type and length fields of 214 the handshake messages. This is the concatenation of all the 215 exchanged Handshake structures, as defined in Section 7.4 of 216 [RFC5246]. 218 For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 219 of [RFC5246] for the Finished message computation. For all previous 220 versions of TLS, the "Hash" function computes the concatenation of 221 MD5 and SHA1. 223 There is no "session_hash" for resumed handshakes, as they do not 224 lead to the creation of a new session. 226 4. The Extended Master Secret 228 When the extended master secret extension is negotiated in a full 229 handshake, the "master_secret" is computed as 231 master_secret = PRF(pre_master_secret, "extended master secret", 232 session_hash) 233 [0..47]; 235 The extended master secret computation differs from the [RFC5246] in 236 the following ways: 238 o The "extended master secret" label is used instead of "master 239 secret"; 241 o The "session_hash" is used instead of the "ClientHello.random" and 242 "ServerHello.random". 244 The "session_hash" depends upon a handshake log that includes 245 "ClientHello.random" and "ServerHello.random", in addition to 246 ciphersuites, key exchange information, and certificates (if any) 247 from the client and server. Consequently, the extended master secret 248 depends upon the choice of all these session parameters. 250 This design reflects the recommendation that keys should be bound to 251 the security contexts that compute them [sp800-108]. The technique 252 of mixing a hash of the key exchange messages into master key 253 derivation is already used in other well-known protocols such as SSH 254 [RFC4251]. 256 Clients and servers SHOULD NOT accept handshakes that do not use the 257 extended master secret, especially if they rely on features like 258 compound authentication that fall into the vulnerable cases described 259 in Section 6.1. 261 5. Extension Negotiation 263 5.1. Extension Definition 265 This document defines a new TLS extension, "extended_master_secret" 266 (with extension type 0x0017), which is used to signal both client and 267 server to use the extended master secret computation. The 268 "extension_data" field of this extension is empty. Thus, the entire 269 encoding of the extension is 00 17 00 00. 271 If the client and server agree on this extension, and a full 272 handshake takes place, both client and server MUST use the extended 273 master secret derivation algorithm, as defined in Section 4. 275 If an abbreviated handshake takes place, the new connection keys are 276 derived as usual from the (extended) master secret of the original 277 handshake that created the resumed session. 279 5.2. Client and Server Behavior: Full Handshake 281 In the following, we use "aborting the handshake" as shorthand for 282 terminating the handshake by sending a fatal "handshake_failure" 283 alert. 285 In all handshakes, a client implementing this document MUST send the 286 "extended_master_secret" extension in its ClientHello. 288 If a server implementing this document receives the 289 "extended_master_secret" extension, it MUST include the 290 "extended_master_secret" extension in its ServerHello message. 292 If the server receives a ClientHello without the extension, it SHOULD 293 abort the handshake. If it chooses to continue, then it MUST NOT 294 include the extension in the ServerHello. 296 If a client receives a ServerHello without the extension, it SHOULD 297 abort the handshake. 299 In a full handshake, if both the ClientHello and ServerHello contain 300 the extension, the new session uses the extended master secret 301 computation. 303 If the client or server choose to continue a full handshake without 304 the extension, they use the legacy master secret derivation for the 305 new session. In this case, the considerations in Section 5.4 apply. 307 5.3. Client and Server Behavior: Abbreviated Handshake 309 The client SHOULD NOT offer an abbreviated handshake to resume a 310 session that does not use an extended master secret. The client MUST 311 send the "extended_master_secret" extension in its ClientHello. 313 If a server receives a ClientHello for an abbreviated handshake 314 offering to resume a previous session, it behaves as follows. 316 o If the original session did not use an extended master secret but 317 the new ClientHello does contain the "extended_master_secret" 318 extension, the server MUST abort the handshake. 320 o If the new ClientHello does not contain the 321 "extended_master_secret" extension, the server SHOULD fall back to 322 a full handshake by sending a ServerHello that rejects the offered 323 session but continues with a full handshake. If it continues with 324 an abbreviated handshake the considerations in Section 5.4 apply. 326 o If the ClientHello contains the extension and the server chooses 327 to accept the abbreviated handshake, then the server MUST include 328 the "extended_master_secret" extension in its ServerHello message. 330 If a client receives a ServerHello that accepts an abbreviated 331 handshake, it behaves as follows. 333 o If the original session did not use an extended master secret but 334 the new ServerHello does contain the "extended_master_secret" 335 extension, the client MUST abort the handshake. 337 o If the new ServerHello does not contain the 338 "extended_master_secret" extension, the client SHOULD abort the 339 handshake. If it continues with an abbreviated handshake the 340 considerations in Section 5.4 apply. 342 If the client and server continue the abbreviated handshake, they 343 derive the connection keys for the new session as usual from the 344 master secret of the original connection. 346 5.4. Interoperability Considerations 348 To allow interoperability with legacy clients and servers, a TLS peer 349 may decide to accept handshakes that use the legacy master secret 350 computation. If so, they need to differentiate between sessions that 351 use legacy and extended master secrets by adding a flag to the 352 session state. 354 If a client or server chooses to continue with a full handshake 355 without the extended master secret extension, the new session is 356 vulnerable to the man-in-the-middle key synchronization attack 357 described in Section 1. Hence, the client or server MUST NOT export 358 any key material based on the new master secret for any subsequent 359 application-level authentication. In particular, it MUST disable 360 [RFC5705] and any EAP protocol relying on compound authentication 361 [COMPOUND-AUTH]. 363 If a client or server chooses to continue an abbreviated handshake to 364 resume a session that does not use the extended master secret, then 365 the current connection is vulnerable to a man-in-the-middle handshake 366 log synchronization attack as described in Section 1. Hence, the 367 client or server MUST NOT use the current handshake's "verify_data" 368 for application-level authentication. In particular, the client 369 should disable renegotiation and any use of the "tls-unique" channel 370 binding [RFC5929] on the current connection. 372 If the original session uses an extended master secret, but the 373 ClientHello or ServerHello in the abbreviated handshake does not 374 include the extension, it MAY be safe to continue the abbreviated 375 handshake since it is protected from the man-in-the-middle attack by 376 the extended master secret. This scenario may occur, for example, 377 when a server that implements this extension establishes a session, 378 but the session is subsequently resumed at a different server that 379 does not support the extension. 381 6. Security Considerations 383 6.1. Triple Handshake Preconditions and Impact 385 One way to mount a triple handshake attack has been described in 386 Section 1, along with a mention of the security mechanisms that break 387 due to the attack; more in-depth discussion and diagrams can be found 388 in [TRIPLE-HS]. Here, some further discussion is presented about 389 attack preconditions and impact. 391 To mount a triple handshake attack, it must be possible to force the 392 same master secret on two different sessions. For this to happen, 393 two preconditions must be met: 395 o The client, C, must be willing to connect to a malicious server, 396 A. In certain contexts, like the web, this can be easily achieved, 397 since a browser can be instructed to load content from an 398 untrusted origin. 400 o The pre-master secret must be synchronized on the two sessions. 401 This is particularly easy to achieve with the RSA and DHE key 402 exchanges, but under some conditions, ECDHE, SRP, and PSK key 403 exchanges can be exploited to this effect as well. 405 Once the master secret is synchronized on two sessions, any security 406 property that relies on the uniqueness of the master secret is 407 compromised. For example, a TLS exporter [RFC5705] no longer 408 provides a unique key bound to the current session. 410 TLS session resumption also relies on the uniqueness of the master 411 secret to authenticate the resuming peers. Hence, if a synchronized 412 session is resumed, the peers cannot be sure about each other 413 identity, and the attacker knows the connection keys. Clearly, a 414 precondition to this step of the attack is that both client and 415 server support session resumption (either via session identifier or 416 session tickets [RFC5077]). 418 Additionally, in a synchronized abbreviated handshake, the whole 419 transcript is synchronized, which includes the "verify_data" values. 420 So, after an abbreviated handshake, channel bindings like "tls- 421 unique" [RFC5929] will not identify uniquely the connection anymore. 423 Synchronization of the "verify_data" in abbreviated handshakes also 424 undermines the security guarantees of the renegotiation indication 425 extension [RFC5746], re-enabling a prefix-injection flaw similar to 426 the renegotiation attack [Ray09]. However, in a triple handshake 427 attack, the client sees the server certificate changing across 428 different full handshakes. Hence, a precondition to mount this stage 429 of the attack is that the client accepts different certificates at 430 each handshake, even if their common names do not match. Before the 431 triple handshake attack was discovered, this used to be widespread 432 behavior, at least among some web browsers, that where hence 433 vulnerable to the attack. 435 The extended master secret extension thwarts triple handshake attacks 436 at their first stage, by ensuring that different sessions necessarily 437 end up with different master secret values. Hence, all security 438 properties relying on the uniqueness of the master secret are now 439 expected to hold. In particular, if a TLS session is protected by 440 the extended master secret extension, it is safe to resume it, to use 441 its channel bindings, and to allow for certificate changes across 442 renegotiation, meaning that all certificates are controlled by the 443 same peer. A symbolic cryptographic protocol analysis justifying the 444 extended master secret extension appears in [VERIFIED-BINDING]. 446 6.2. Cryptographic Properties of the Hash Function 448 The session hashes of two different sessions need to be distinct, 449 hence the "Hash" function used to compute the "session_hash" needs to 450 be collision resistant. As such, hash functions such as MD5 or SHA1 451 are NOT RECOMMENDED. 453 We observe that the "Hash" function used in the Finished message 454 computation already needs to be collision resistant, for the 455 renegotiation indication extension [RFC5746] to work: a collision on 456 the verify_data (and hence on the hash function computing the 457 handshake messages hash) defeats the renegotiation indication 458 countermeasure. 460 The hash function used to compute the session hash depends on the TLS 461 protocol version. All current ciphersuites defined for TLS 1.2 use 462 SHA256 or better, and so does the session hash. For earlier versions 463 of the protocol, only MD5 and SHA1 can be assumed to be supported, 464 and this document does not require legacy implementations to add 465 support for new hash functions. In these versions, the session hash 466 uses the concatenation of MD5 and SHA1, as in the Finished message. 468 6.3. Handshake Messages included in the Session Hash 470 The "session_hash" is intended to encompass all relevant session 471 information, including ciphersuite negotiation, key exchange messages 472 and client and server identities. The session hash needs to be 473 available to compute the extended master secret before the Finished 474 messages. 476 This document sets the "session_hash" to cover all handshake messages 477 up to and including the ClientKeyExchange. For existing TLS 478 ciphersuites, these messages include all the significant contents of 479 the new session---CertificateVerify does not change the session 480 content. At the same time, this allows the extended master secret to 481 be computed immediately after the pre-master secret, so that 482 implementations can shred the temporary pre-master secret from memory 483 as early as possible. 485 It is possible that new ciphersuites or TLS extensions may include 486 additional messages between ClientKeyExchange and Finished that add 487 important session context. In such cases, some of the security 488 guarantees of this specification may no longer apply, and new man-in- 489 the-middle attacks may be possible. For example, if the client and 490 server support the session ticket extension [RFC5077], the session 491 hash does not cover the new session ticket sent by the server/ Hence, 492 a man-in-the-middle may be able to cause a client to store a session 493 ticket that was not meant for the current session. Attacks based on 494 this vector are not yet known, but applications that store additional 495 information in session tickets beyond those covered in the session 496 hash require careful analysis. 498 6.4. No SSL 3.0 Support 500 SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is 501 equally vulnerable to the triple handshake attacks, alongside other 502 vulnerabilities stemming from its use of obsolete cryptographic 503 constructions that are now considered weak. 505 The countermeasure described in this document relies on a TLS 506 extension and hence cannot be used with SSL 3.0. Clients and servers 507 implementing this document SHOULD refuse SSL 3.0 handshakes. If they 508 choose to support SSL 3.0, the resulting sessions MUST use the legacy 509 master secret computation, and the interoperability considerations of 510 Section 5.4 apply. 512 7. IANA Considerations 514 IANA has added the extension code point 23 (0x0017), which has been 515 used by prototype implementations, for the "extended_master_secret" 516 extension to the TLS ExtensionType values registry as specified in 517 TLS [RFC5246]. 519 8. Acknowledgments 521 The triple handshake attacks were originally discovered by Antoine 522 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 523 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 524 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 525 ideas in this draft emerged from discussions with Martin Abadi, Ben 526 Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric 527 Rescorla, Martin Rex, Brian Smith. 529 9. References 531 9.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 537 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 539 9.2. Informative References 541 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 542 "Transport Layer Security (TLS) Renegotiation Indication 543 Extension", RFC 5746, February 2010. 545 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 546 Layer Security (TLS)", RFC 5705, March 2010. 548 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 549 for TLS", RFC 5929, July 2010. 551 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 552 Protocol Architecture", RFC 4251, January 2006. 554 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 555 "Transport Layer Security (TLS) Session Resumption without 556 Server-Side State", RFC 5077, January 2008. 558 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 559 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 560 August 2011. 562 [TRIPLE-HS] 563 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 564 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 565 Breaking and Fixing Authentication over TLS", IEEE 566 Symposium on Security and Privacy (Oakland'14) , 2014. 568 [VERIFIED-BINDING] 569 Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 570 "Verified Contributive Channel Bindings for Compound 571 Authentication", Network and Distributed System Security 572 Symposium (NDSS'14) , 2015. 574 [sp800-108] 575 Chen, L., "NIST Special Publication 800-108: 576 Recommendation for Key Derivation Using Pseudorandom 577 Functions", 2009. 579 [COMPOUND-AUTH] 580 Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the- 581 middle in tunnelled authentication protocols", 2005. 583 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 585 Authors' Addresses 587 Karthikeyan Bhargavan 588 Inria Paris-Rocquencourt 589 23, Avenue d'Italie 590 Paris 75214 CEDEX 13 591 France 593 Email: karthikeyan.bhargavan@inria.fr 595 Antoine Delignat-Lavaud 596 Inria Paris-Rocquencourt 597 23, Avenue d'Italie 598 Paris 75214 CEDEX 13 599 France 601 Email: antoine.delignat-lavaud@inria.fr 603 Alfredo Pironti 604 Inria Paris-Rocquencourt 605 23, Avenue d'Italie 606 Paris 75214 CEDEX 13 607 France 609 Email: alfredo.pironti@inria.fr 610 Adam Langley 611 Google Inc. 612 1600 Amphitheatre Parkway 613 Mountain View, CA 94043 614 USA 616 Email: agl@google.com 618 Marsh Ray 619 Microsoft Corp. 620 1 Microsoft Way 621 Redmond, WA 98052 622 USA 624 Email: maray@microsoft.com