idnits 2.17.1 draft-ietf-tls-session-hash-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. 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. (Using the creation date from RFC5246, updated by this document, for RFC5378 checks: 2006-03-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2015) is 3216 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 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 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 Updates: 5246 (if approved) A. Pironti 5 Intended status: Standards Track Inria Paris-Rocquencourt 6 Expires: January 6, 2016 A. Langley 7 Google Inc. 8 M. Ray 9 Microsoft Corp. 10 July 5, 2015 12 Transport Layer Security (TLS) Session Hash and 13 Extended Master Secret Extension 14 draft-ietf-tls-session-hash-06 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 January 6, 2016. 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 . . . . . . 11 77 6.3. Handshake Messages included in the Session Hash . . . . . 11 78 6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 9.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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, called the "triple handshake", that 181 circumvents the protections of [RFC5746] to break client- 182 authenticated TLS renegotiation after session resumption. Similar 183 attacks apply to application-level authentication mechanisms that 184 rely on channel bindings [RFC5929] or on key material exported from 185 TLS [RFC5705]. 187 The underlying protocol issue leading to these attacks is that the 188 TLS master secret is not guaranteed to be unique across sessions, 189 since it is not context-bound to the full handshake that generated 190 it. If we fix this problem in the initial master secret computation, 191 all these attacks can be prevented. This specification introduces a 192 TLS extension that changes the way the "master_secret" value is 193 computed in a full handshake by including the log of the handshake 194 messages, so that different sessions will, by construction, have 195 different master secrets. This prevents the attacks described in 196 [TRIPLE-HS] and documented in Section 2.11 of [RFC7457]. 198 2. Requirements Notation 200 This document uses the same notation and terminology used in the TLS 201 Protocol specification [RFC5246]. 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 3. The TLS Session Hash 209 When a full TLS handshake takes place, we define 211 session_hash = Hash(handshake_messages) 213 where "handshake_messages" refers to all handshake messages sent or 214 received, starting at the ClientHello up to and including the 215 ClientKeyExchange message, including the type and length fields of 216 the handshake messages. This is the concatenation of all the 217 exchanged Handshake structures, as defined in Section 7.4 of 218 [RFC5246]. 220 For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 221 of [RFC5246] for the Finished message computation. For all previous 222 versions of TLS, the "Hash" function computes the concatenation of 223 MD5 and SHA1. 225 There is no "session_hash" for resumed handshakes, as they do not 226 lead to the creation of a new session. 228 4. The Extended Master Secret 230 When the extended master secret extension is negotiated in a full 231 handshake, the "master_secret" is computed as 233 master_secret = PRF(pre_master_secret, "extended master secret", 234 session_hash) 235 [0..47]; 237 The extended master secret computation differs from the [RFC5246] in 238 the following ways: 240 o The "extended master secret" label is used instead of "master 241 secret"; 243 o The "session_hash" is used instead of the "ClientHello.random" and 244 "ServerHello.random". 246 The "session_hash" depends upon a handshake log that includes 247 "ClientHello.random" and "ServerHello.random", in addition to 248 ciphersuites, key exchange information, and certificates (if any) 249 from the client and server. Consequently, the extended master secret 250 depends upon the choice of all these session parameters. 252 This design reflects the recommendation that keys should be bound to 253 the security contexts that compute them [SP800-108]. The technique 254 of mixing a hash of the key exchange messages into master key 255 derivation is already used in other well-known protocols such as SSH 256 [RFC4251]. 258 Clients and servers SHOULD NOT accept handshakes that do not use the 259 extended master secret, especially if they rely on features like 260 compound authentication that fall into the vulnerable cases described 261 in Section 6.1. 263 5. Extension Negotiation 265 5.1. Extension Definition 267 This document defines a new TLS extension, "extended_master_secret" 268 (with extension type 0x0017), which is used to signal both client and 269 server to use the extended master secret computation. The 270 "extension_data" field of this extension is empty. Thus, the entire 271 encoding of the extension is 00 17 00 00 (in hexadecimal.) 273 Although this document refers only to TLS, the extension proposed 274 here can also be used with Datagram TLS (DTLS) [RFC6347]. 276 If the client and server agree on this extension, and a full 277 handshake takes place, both client and server MUST use the extended 278 master secret derivation algorithm, as defined in Section 4. All 279 other cryptographic computations remain unchanged. 281 5.2. Client and Server Behavior: Full Handshake 283 In the following, we use the phrase "abort the handshake" as 284 shorthand for terminating the handshake by sending a fatal 285 "handshake_failure" alert. 287 In all handshakes, a client implementing this document MUST send the 288 "extended_master_secret" extension in its ClientHello. 290 If a server implementing this document receives the 291 "extended_master_secret" extension, it MUST include the extension in 292 its ServerHello message. 294 If both the ClientHello and ServerHello contain the extension, the 295 new session uses the extended master secret computation. 297 If the server receives a ClientHello without the extension, it SHOULD 298 abort the handshake if it does not wish to interoperate with legacy 299 clients. If it chooses to continue the handshake, then it MUST NOT 300 include the extension in the ServerHello. 302 If a client receives a ServerHello without the extension, it SHOULD 303 abort the handshake if it does not wish to interoperate with legacy 304 servers. 306 If the client and server choose to continue a full handshake without 307 the extension, they MUST use the standard master secret derivation 308 for the new session. In this case, the new session is not protected 309 by the mechanisms described in this document. So, implementers 310 should follow the guidelines in Section 5.4 to avoid dangerous usage 311 scenarios. In particular, the master secret derived from the new 312 session should not be used for application-level authentication. 314 5.3. Client and Server Behavior: Abbreviated Handshake 316 The client SHOULD NOT offer an abbreviated handshake to resume a 317 session that does not use an extended master secret. Instead, it 318 SHOULD offer a full handshake. 320 If the client chooses to offer an abbreviated handshake even for such 321 sessions, in order to support legacy insecure resumption, then the 322 current connection is not protected by the mechanisms in this 323 document. So, the client should follow the guidelines in Section 5.4 324 to avoid dangerous usage scenarios. In particular, renegotiation is 325 no longer secure on this connection, even if the client and server 326 support the renegotiation indication extension [RFC5746]. 328 When offering an abbreviated handshake, the client MUST send the 329 "extended_master_secret" extension in its ClientHello. 331 If a server receives a ClientHello for an abbreviated handshake 332 offering to resume a known previous session, it behaves as follows: 334 o If the original session did not use the "extended_master_secret" 335 extension but the new ClientHello contains the extension, then the 336 server MUST NOT perform the abbreviated handshake. Instead, it 337 SHOULD continue with a full handshake (as described in 338 Section 5.2) to negotiate a new session. 340 o If the original session used the "extended_master_secret" 341 extension but the new ClientHello does not contain the extension, 342 the server MUST abort the abbreviated handshake. 344 o If neither the original session nor the new ClientHello uses the 345 extension, the server SHOULD abort the handshake. If it continues 346 with an abbreviated handshake in order to support legacy insecure 347 resumption, the connection is no longer protected by the 348 mechanisms in this document, and the server should follow the 349 guidelines in Section 5.4. 351 o If the new ClientHello contains the extension and the server 352 chooses to continue the handshake, then the server MUST include 353 the "extended_master_secret" extension in its ServerHello message. 355 If a client receives a ServerHello that accepts an abbreviated 356 handshake, it behaves as follows: 358 o If the original session did not use the "extended_master_secret" 359 extension but the new ServerHello contains the extension, the 360 client MUST abort the handshake. 362 o If the original session used the extension but the new ServerHello 363 does not contain the extension, the client MUST abort the 364 handshake. 366 If the client and server continue the abbreviated handshake, they 367 derive the connection keys for the new session as usual from the 368 master secret of the original session. 370 5.4. Interoperability Considerations 372 To allow interoperability with legacy clients and servers, a TLS peer 373 may decide to accept full handshakes that use the legacy master 374 secret computation. If so, they need to differentiate between 375 sessions that use legacy and extended master secrets by adding a flag 376 to the session state. 378 If a client or server chooses to continue with a full handshake 379 without the extended master secret extension, then the new session 380 becomes vulnerable to the man-in-the-middle key synchronization 381 attack described in Section 1. Hence, the client or server MUST NOT 382 export any key material based on the new master secret for any 383 subsequent application-level authentication. In particular, it MUST 384 disable [RFC5705] and any EAP protocol relying on compound 385 authentication [COMPOUND-AUTH]. 387 If a client or server chooses to continue an abbreviated handshake to 388 resume a session that does not use the extended master secret, then 389 the current connection becomes vulnerable to a man-in-the-middle 390 handshake log synchronization attack as described in Section 1. 391 Hence, the client or server MUST NOT use the current handshake's 392 "verify_data" for application-level authentication. In particular, 393 the client MUST disable renegotiation and any use of the "tls-unique" 394 channel binding [RFC5929] on the current connection. 396 If the original session uses an extended master secret, but the 397 ClientHello or ServerHello in the abbreviated handshake does not 398 include the extension, it MAY be safe to continue the abbreviated 399 handshake since it is protected by the extended master secret of the 400 original session. This scenario may occur, for example, when a 401 server that implements this extension establishes a session, but the 402 session is subsequently resumed at a different server that does not 403 support the extension. Since such situations are unusual and likely 404 to be the result of transient or inadvertent misconfigurations, this 405 draft recommends that the client and server MUST abort such 406 handshakes. 408 6. Security Considerations 410 6.1. Triple Handshake Preconditions and Impact 412 One way to mount a triple handshake attack has been described in 413 Section 1, along with a mention of the security mechanisms that break 414 due to the attack; more in-depth discussion and diagrams can be found 415 in [TRIPLE-HS]. Here, some further discussion is presented about 416 attack preconditions and impact. 418 To mount a triple handshake attack, it must be possible to force the 419 same master secret on two different sessions. For this to happen, 420 two preconditions must be met: 422 o The client, C, must be willing to connect to a malicious server, 423 A. In certain contexts, like the web, this can be easily 424 achieved, since a browser can be instructed to load content from 425 an untrusted origin. 427 o The pre-master secret must be synchronized on the two sessions. 428 This is particularly easy to achieve with the RSA and DHE key 429 exchanges, but under some conditions, ECDHE, SRP, and PSK key 430 exchanges can be exploited to this effect as well. 432 Once the master secret is synchronized on two sessions, any security 433 property that relies on the uniqueness of the master secret is 434 compromised. For example, a TLS exporter [RFC5705] no longer 435 provides a unique key bound to the current session. 437 TLS session resumption also relies on the uniqueness of the master 438 secret to authenticate the resuming peers. Hence, if a synchronized 439 session is resumed, the peers cannot be sure about each other's 440 identities, and the attacker knows the connection keys. Clearly, a 441 precondition to this step of the attack is that both client and 442 server support session resumption (either via session identifier or 443 session tickets [RFC5077]). 445 Additionally, in a synchronized abbreviated handshake, the whole 446 transcript is synchronized, which includes the "verify_data" values. 447 So, after an abbreviated handshake, channel bindings like "tls- 448 unique" [RFC5929] will not identify uniquely the connection anymore. 450 Synchronization of the "verify_data" in abbreviated handshakes also 451 undermines the security guarantees of the renegotiation indication 452 extension [RFC5746], re-enabling a prefix-injection flaw similar to 453 the renegotiation attack [Ray09]. However, in a triple handshake 454 attack, the client sees the server certificate changing across 455 different full handshakes. Hence, a precondition to mount this stage 456 of the attack is that the client accepts different certificates at 457 each handshake, even if their common names do not match. Before the 458 triple handshake attack was discovered, this used to be widespread 459 behavior, at least among some web browsers, that were hence 460 vulnerable to the attack. 462 The extended master secret extension thwarts triple handshake attacks 463 at their first stage, by ensuring that different sessions necessarily 464 end up with different master secret values. Hence, all security 465 properties relying on the uniqueness of the master secret are now 466 expected to hold. In particular, if a TLS session is protected by 467 the extended master secret extension, it is safe to resume it, to use 468 its channel bindings, and to allow for certificate changes across 469 renegotiation, meaning that all certificates are controlled by the 470 same peer. A symbolic cryptographic protocol analysis justifying the 471 extended master secret extension appears in [VERIFIED-BINDINGS]. 473 6.2. Cryptographic Properties of the Hash Function 475 The session hashes of two different sessions need to be distinct, 476 hence the "Hash" function used to compute the "session_hash" needs to 477 be collision resistant. As such, hash functions such as MD5 or SHA1 478 are NOT RECOMMENDED. 480 We observe that the "Hash" function used in the Finished message 481 computation already needs to be collision resistant for the 482 renegotiation indication extension [RFC5746] to work, because a 483 meaningful collision on the handshake messages (and hence on the 484 "verify_data") may re-enable the renegotiation attack [Ray09]. 486 The hash function used to compute the session hash depends on the TLS 487 protocol version. All current ciphersuites defined for TLS 1.2 use 488 SHA256 or better, and so does the session hash. For earlier versions 489 of the protocol, only MD5 and SHA1 can be assumed to be supported, 490 and this document does not require legacy implementations to add 491 support for new hash functions. In these versions, the session hash 492 uses the concatenation of MD5 and SHA1, as in the Finished message. 494 6.3. Handshake Messages included in the Session Hash 496 The "session_hash" is intended to encompass all relevant session 497 information, including ciphersuite negotiation, key exchange messages 498 and client and server identities. The hash is needed to compute the 499 extended master secret, and hence must be available before the 500 Finished messages. 502 This document sets the "session_hash" to cover all handshake messages 503 up to and including the ClientKeyExchange. For existing TLS 504 ciphersuites, these messages include all the significant contents of 505 the new session---CertificateVerify does not change the session 506 content. At the same time, this allows the extended master secret to 507 be computed immediately after the pre-master secret, so that 508 implementations can shred the temporary pre-master secret from memory 509 as early as possible. 511 It is possible that new ciphersuites or TLS extensions may include 512 additional messages between ClientKeyExchange and Finished that add 513 important session context. In such cases, some of the security 514 guarantees of this specification may no longer apply, and new man-in- 515 the-middle attacks may be possible. For example, if the client and 516 server support the session ticket extension [RFC5077], the session 517 hash does not cover the new session ticket sent by the server. 518 Hence, a man-in-the-middle may be able to cause a client to store a 519 session ticket that was not meant for the current session. Attacks 520 based on this vector are not yet known, but applications that store 521 additional information in session tickets beyond those covered in the 522 session hash require careful analysis. 524 6.4. No SSL 3.0 Support 526 SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is 527 equally vulnerable to the triple handshake attacks, alongside other 528 vulnerabilities stemming from its use of obsolete cryptographic 529 constructions that are now considered weak. SSL 3.0 has been 530 deprecated [I-D.ietf-tls-sslv3-diediedie]. 532 The countermeasure described in this document relies on a TLS 533 extension and hence cannot be used with SSL 3.0. Clients and servers 534 implementing this document SHOULD refuse SSL 3.0 handshakes. If they 535 choose to support SSL 3.0, the resulting sessions MUST use the legacy 536 master secret computation, and the interoperability considerations of 537 Section 5.4 apply. 539 7. IANA Considerations 541 IANA has added the extension code point 23 (0x0017), which has been 542 used by prototype implementations, for the "extended_master_secret" 543 extension to the TLS ExtensionType values registry as specified in 544 TLS [RFC5246]. 546 8. Acknowledgments 548 The triple handshake attacks were originally discovered by Antoine 549 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were 550 further developed by the miTLS team: Cedric Fournet, Pierre-Yves 551 Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the 552 ideas in this draft emerged from discussions with Martin Abadi, Ben 553 Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric 554 Rescorla, Martin Rex, Brian Smith. 556 9. References 558 9.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, March 1997. 563 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 564 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 566 9.2. Informative References 568 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 569 "Transport Layer Security (TLS) Renegotiation Indication 570 Extension", RFC 5746, February 2010. 572 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 573 Security Version 1.2", RFC 6347, January 2012. 575 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 576 Layer Security (TLS)", RFC 5705, March 2010. 578 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 579 for TLS", RFC 5929, July 2010. 581 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 582 Protocol Architecture", RFC 4251, January 2006. 584 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 585 "Transport Layer Security (TLS) Session Resumption without 586 Server-Side State", RFC 5077, January 2008. 588 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 589 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 590 August 2011. 592 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 593 Known Attacks on Transport Layer Security (TLS) and 594 Datagram TLS (DTLS)", RFC 7457, February 2015. 596 [I-D.ietf-tls-sslv3-diediedie] 597 Barnes, R., Thomson, M., Pironti, A., and A. Langley, 598 "Deprecating Secure Sockets Layer Version 3.0", draft- 599 ietf-tls-sslv3-diediedie-03 (work in progress), April 600 2015. 602 [TRIPLE-HS] 603 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 604 A., and P-Y. Strub, "Triple Handshakes and Cookie Cutters: 605 Breaking and Fixing Authentication over TLS", IEEE 606 Symposium on Security and Privacy (Oakland) , 2014. 608 [VERIFIED-BINDINGS] 609 Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, 610 "Verified Contributive Channel Bindings for Compound 611 Authentication", Network and Distributed System Security 612 Symposium (NDSS) , 2015. 614 [SP800-108] 615 Chen, L., "Recommendation for Key Derivation Using 616 Pseudorandom Functions (Revised)", NIST Special 617 Publication 800-108 , 2009. 619 [COMPOUND-AUTH] 620 Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the- 621 middle in tunnelled authentication protocols", Security 622 Protocols, Springer LNCS Volume 3364 , 2005. 624 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009. 626 Authors' Addresses 628 Karthikeyan Bhargavan (editor) 629 Inria Paris-Rocquencourt 630 23, Avenue d'Italie 631 Paris 75214 CEDEX 13 632 France 634 Email: karthikeyan.bhargavan@inria.fr 636 Antoine Delignat-Lavaud 637 Inria Paris-Rocquencourt 638 23, Avenue d'Italie 639 Paris 75214 CEDEX 13 640 France 642 Email: antoine.delignat-lavaud@inria.fr 644 Alfredo Pironti 645 Inria Paris-Rocquencourt 646 23, Avenue d'Italie 647 Paris 75214 CEDEX 13 648 France 650 Email: alfredo.pironti@inria.fr 652 Adam Langley 653 Google Inc. 654 1600 Amphitheatre Parkway 655 Mountain View, CA 94043 656 USA 658 Email: agl@google.com 659 Marsh Ray 660 Microsoft Corp. 661 1 Microsoft Way 662 Redmond, WA 98052 663 USA 665 Email: maray@microsoft.com