idnits 2.17.1 draft-ietf-tls-session-hash-05.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 issues found here. 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 (April 16, 2015) is 3298 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Bhargavan, Ed. 3 Internet-Draft A. Delignat-Lavaud 4 Intended status: Standards Track A. Pironti 5 Expires: October 18, 2015 Inria Paris-Rocquencourt 6 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 April 16, 2015 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-ietf-tls-session-hash-05 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 October 18, 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 138 on 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-BINDINGS]. 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 (in hexadecimal.) 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 Some clients and servers may choose to continue a full handshake 304 without the extension, in order to interoperate with legacy peers. 305 In this case, they use the standard master secret derivation for the 306 new session, and the considerations in Section 5.4 apply. 308 5.3. Client and Server Behavior: Abbreviated Handshake 310 The client SHOULD NOT offer an abbreviated handshake to resume a 311 session that does not use an extended master secret. The client MUST 312 send the "extended_master_secret" extension in its ClientHello. 314 If a server receives a ClientHello for an abbreviated handshake 315 offering to resume a previous session, it behaves as follows. 317 o If the new ClientHello does not contain the 318 "extended_master_secret" extension, the server SHOULD abort the 319 handshake. If it continues with an abbreviated handshake in order 320 to interoperate with legacy peers, then the considerations in 321 Section 5.4 apply. 323 o If the original session did not use an extended master secret but 324 the new ClientHello does contain the "extended_master_secret" 325 extension, the server MUST NOT perform the abbreviated handshake. 326 Instead, it SHOULD continue with a full handshake to negotiate a 327 new session. 329 o If the ClientHello contains the extension and the server decides 330 to accept the abbreviated handshake, then the server MUST include 331 the "extended_master_secret" extension in its ServerHello message. 333 If a client receives a ServerHello that accepts an abbreviated 334 handshake, it behaves as follows. 336 o If the original session did not use an extended master secret but 337 the new ServerHello does contain the "extended_master_secret" 338 extension, the client MUST abort the handshake. 340 o If the new ServerHello does not contain the 341 "extended_master_secret" extension, the client SHOULD abort the 342 handshake. If it continues with an abbreviated handshake in order 343 to interoperate with legacy peers, then the considerations in 344 Section 5.4 apply. 346 If the client and server continue the abbreviated handshake, they 347 derive the connection keys for the new session as usual from the 348 master secret of the original connection. 350 5.4. Interoperability Considerations 352 To allow interoperability with legacy clients and servers, a TLS peer 353 may decide to accept handshakes that use the legacy master secret 354 computation. If so, they need to differentiate between sessions that 355 use legacy and extended master secrets by adding a flag to the 356 session state. 358 If a client or server chooses to continue with a full handshake 359 without the extended master secret extension, the new session is 360 vulnerable to the man-in-the-middle key synchronization attack 361 described in Section 1. Hence, the client or server MUST NOT export 362 any key material based on the new master secret for any subsequent 363 application-level authentication. In particular, it MUST disable 364 [RFC5705] and any EAP protocol relying on compound authentication 365 [COMPOUND-AUTH]. 367 If a client or server chooses to continue an abbreviated handshake to 368 resume a session that does not use the extended master secret, then 369 the current connection is vulnerable to a man-in-the-middle handshake 370 log synchronization attack as described in Section 1. Hence, the 371 client or server MUST NOT use the current handshake's "verify_data" 372 for application-level authentication. In particular, the client 373 should disable renegotiation and any use of the "tls-unique" channel 374 binding [RFC5929] on the current connection. 376 If the original session uses an extended master secret, but the 377 ClientHello or ServerHello in the abbreviated handshake does not 378 include the extension, it MAY be safe to continue the abbreviated 379 handshake since it is protected from the man-in-the-middle attack by 380 the extended master secret. This scenario may occur, for example, 381 when a server that implements this extension establishes a session, 382 but the session is subsequently resumed at a different server that 383 does not support the extension. 385 6. Security Considerations 387 6.1. Triple Handshake Preconditions and Impact 389 One way to mount a triple handshake attack has been described in 390 Section 1, along with a mention of the security mechanisms that break 391 due to the attack; more in-depth discussion and diagrams can be found 392 in [TRIPLE-HS]. Here, some further discussion is presented about 393 attack preconditions and impact. 395 To mount a triple handshake attack, it must be possible to force the 396 same master secret on two different sessions. For this to happen, 397 two preconditions must be met: 399 o The client, C, must be willing to connect to a malicious server, 400 A. In certain contexts, like the web, this can be easily 401 achieved, since a browser can be instructed to load content from 402 an untrusted origin. 404 o The pre-master secret must be synchronized on the two sessions. 405 This is particularly easy to achieve with the RSA and DHE key 406 exchanges, but under some conditions, ECDHE, SRP, and PSK key 407 exchanges can be exploited to this effect as well. 409 Once the master secret is synchronized on two sessions, any security 410 property that relies on the uniqueness of the master secret is 411 compromised. For example, a TLS exporter [RFC5705] no longer 412 provides a unique key bound to the current session. 414 TLS session resumption also relies on the uniqueness of the master 415 secret to authenticate the resuming peers. Hence, if a synchronized 416 session is resumed, the peers cannot be sure about each other's 417 identities, and the attacker knows the connection keys. Clearly, a 418 precondition to this step of the attack is that both client and 419 server support session resumption (either via session identifier or 420 session tickets [RFC5077]). 422 Additionally, in a synchronized abbreviated handshake, the whole 423 transcript is synchronized, which includes the "verify_data" values. 424 So, after an abbreviated handshake, channel bindings like "tls- 425 unique" [RFC5929] will not identify uniquely the connection anymore. 427 Synchronization of the "verify_data" in abbreviated handshakes also 428 undermines the security guarantees of the renegotiation indication 429 extension [RFC5746], re-enabling a prefix-injection flaw similar to 430 the renegotiation attack [Ray09]. However, in a triple handshake 431 attack, the client sees the server certificate changing across 432 different full handshakes. Hence, a precondition to mount this stage 433 of the attack is that the client accepts different certificates at 434 each handshake, even if their common names do not match. Before the 435 triple handshake attack was discovered, this used to be widespread 436 behavior, at least among some web browsers, that were hence 437 vulnerable to the attack. 439 The extended master secret extension thwarts triple handshake attacks 440 at their first stage, by ensuring that different sessions necessarily 441 end up with different master secret values. Hence, all security 442 properties relying on the uniqueness of the master secret are now 443 expected to hold. In particular, if a TLS session is protected by 444 the extended master secret extension, it is safe to resume it, to use 445 its channel bindings, and to allow for certificate changes across 446 renegotiation, meaning that all certificates are controlled by the 447 same peer. A symbolic cryptographic protocol analysis justifying the 448 extended master secret extension appears in [VERIFIED-BINDINGS]. 450 6.2. Cryptographic Properties of the Hash Function 452 The session hashes of two different sessions need to be distinct, 453 hence the "Hash" function used to compute the "session_hash" needs to 454 be collision resistant. As such, hash functions such as MD5 or SHA1 455 are NOT RECOMMENDED. 457 We observe that the "Hash" function used in the Finished message 458 computation already needs to be collision resistant for the 459 renegotiation indication extension [RFC5746] to work, because a 460 meaningful collision on the handshake messages (and hence on the 461 "verify_data") may re-enable the renegotiation attack [Ray09]. 463 The hash function used to compute the session hash depends on the TLS 464 protocol version. All current ciphersuites defined for TLS 1.2 use 465 SHA256 or better, and so does the session hash. For earlier versions 466 of the protocol, only MD5 and SHA1 can be assumed to be supported, 467 and this document does not require legacy implementations to add 468 support for new hash functions. In these versions, the session hash 469 uses the concatenation of MD5 and SHA1, as in the Finished message. 471 6.3. Handshake Messages included in the Session Hash 473 The "session_hash" is intended to encompass all relevant session 474 information, including ciphersuite negotiation, key exchange messages 475 and client and server identities. The session hash needs to be 476 available to compute the extended master secret before the Finished 477 messages. 479 This document sets the "session_hash" to cover all handshake messages 480 up to and including the ClientKeyExchange. For existing TLS 481 ciphersuites, these messages include all the significant contents of 482 the new session---CertificateVerify does not change the session 483 content. At the same time, this allows the extended master secret to 484 be computed immediately after the pre-master secret, so that 485 implementations can shred the temporary pre-master secret from memory 486 as early as possible. 488 It is possible that new ciphersuites or TLS extensions may include 489 additional messages between ClientKeyExchange and Finished that add 490 important session context. In such cases, some of the security 491 guarantees of this specification may no longer apply, and new man-in- 492 the-middle attacks may be possible. For example, if the client and 493 server support the session ticket extension [RFC5077], the session 494 hash does not cover the new session ticket sent by the server. 495 Hence, a man-in-the-middle may be able to cause a client to store a 496 session ticket that was not meant for the current session. Attacks 497 based on this vector are not yet known, but applications that store 498 additional information in session tickets beyond those covered in the 499 session hash require careful analysis. 501 6.4. No SSL 3.0 Support 503 SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is 504 equally vulnerable to the triple handshake attacks, alongside other 505 vulnerabilities stemming from its use of obsolete cryptographic 506 constructions that are now considered weak. 508 The countermeasure described in this document relies on a TLS 509 extension and hence cannot be used with SSL 3.0. Clients and servers 510 implementing this document SHOULD refuse SSL 3.0 handshakes. If they 511 choose to support SSL 3.0, the resulting sessions MUST use the legacy 512 master secret computation, and the interoperability considerations of 513 Section 5.4 apply. 515 7. IANA Considerations 517 IANA has added the extension code point 23 (0x0017), which has been 518 used by prototype implementations, for the "extended_master_secret" 519 extension to the TLS ExtensionType values registry as specified in 520 TLS [RFC5246]. 522 8. Acknowledgments 524 The triple handshake attacks were originally discovered by Antoine 525 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 526 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 527 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 528 ideas in this draft emerged from discussions with Martin Abadi, Ben 529 Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric 530 Rescorla, Martin Rex, Brian Smith. 532 9. References 534 9.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 540 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 542 9.2. Informative References 544 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 545 "Transport Layer Security (TLS) Renegotiation Indication 546 Extension", RFC 5746, February 2010. 548 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 549 Layer Security (TLS)", RFC 5705, March 2010. 551 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 552 for TLS", RFC 5929, July 2010. 554 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 555 Protocol Architecture", RFC 4251, January 2006. 557 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 558 "Transport Layer Security (TLS) Session Resumption without 559 Server-Side State", RFC 5077, January 2008. 561 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 562 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 563 August 2011. 565 [TRIPLE-HS] 566 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 567 A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: 568 Breaking and Fixing Authentication over TLS", IEEE 569 Symposium on Security and Privacy (Oakland) , 2014. 571 [VERIFIED-BINDINGS] 572 Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 573 "Verified Contributive Channel Bindings for Compound 574 Authentication", Network and Distributed System Security 575 Symposium (NDSS) , 2015. 577 [SP800-108] 578 Chen, L., "Recommendation for Key Derivation Using 579 Pseudorandom Functions (Revised)", NIST Special 580 Publication 800-108 , 2009. 582 [COMPOUND-AUTH] 583 Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the- 584 middle in tunnelled authentication protocols", Security 585 Protocols, Springer LNCS Volume 3364 , 2005. 587 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 589 Authors' Addresses 591 Karthikeyan Bhargavan (editor) 592 Inria Paris-Rocquencourt 593 23, Avenue d'Italie 594 Paris 75214 CEDEX 13 595 France 597 Email: karthikeyan.bhargavan@inria.fr 599 Antoine Delignat-Lavaud 600 Inria Paris-Rocquencourt 601 23, Avenue d'Italie 602 Paris 75214 CEDEX 13 603 France 605 Email: antoine.delignat-lavaud@inria.fr 607 Alfredo Pironti 608 Inria Paris-Rocquencourt 609 23, Avenue d'Italie 610 Paris 75214 CEDEX 13 611 France 613 Email: alfredo.pironti@inria.fr 614 Adam Langley 615 Google Inc. 616 1600 Amphitheatre Parkway 617 Mountain View, CA 94043 618 USA 620 Email: agl@google.com 622 Marsh Ray 623 Microsoft Corp. 624 1 Microsoft Way 625 Redmond, WA 98052 626 USA 628 Email: maray@microsoft.com