7Internet Engineering Task Force (IETF) K. Bhargavan, Ed.
8Request for Comments: 7627 A. Delignat-Lavaud
9Updates: 5246 A. Pironti
10Category: Standards Track Inria Paris-Rocquencourt
11ISSN: 2070-1721 A. Langley
18 Transport Layer Security (TLS) Session Hash and
19 Extended Master Secret Extension
23 The Transport Layer Security (TLS) master secret is not
24 cryptographically bound to important session parameters such as the
25 server certificate. Consequently, it is possible for an active
26 attacker to set up two sessions, one with a client and another with a
27 server, such that the master secrets on the two sessions are the
28 same. Thereafter, any mechanism that relies on the master secret for
29 authentication, including session resumption, becomes vulnerable to a
30 man-in-the-middle attack, where the attacker can simply forward
31 messages back and forth between the client and server. This
32 specification defines a TLS extension that contextually binds the
33 master secret to a log of the full handshake that computes it, thus
34 preventing such attacks.
38 This is an Internet Standards Track document.
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Further information on
44 Internet Standards is available in Section 2 of RFC 5741.
46 Information about the current status of this document, any errata,
47 and how to provide feedback on it may be obtained at
48 http://www.rfc-editor.org/info/rfc7627.
58Bhargavan, et al. Standards Track [Page 1]
60RFC 7627 TLS Session Hash Extension September 2015
65 Copyright (c) 2015 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction ....................................................3
81 2. Requirements Notation ...........................................5
82 3. The TLS Session Hash ............................................5
83 4. The Extended Master Secret ......................................6
84 5. Extension Negotiation ...........................................6
85 5.1. Extension Definition .......................................6
86 5.2. Client and Server Behavior: Full Handshake .................7
87 5.3. Client and Server Behavior: Abbreviated Handshake ..........7
88 5.4. Interoperability Considerations ............................9
89 6. Security Considerations .........................................9
90 6.1. Triple Handshake Preconditions and Impact ..................9
91 6.2. Cryptographic Properties of the Hash Function .............11
92 6.3. Handshake Messages Included in the Session Hash ...........11
93 6.4. No SSL 3.0 Support ........................................12
94 7. IANA Considerations ............................................12
95 8. References .....................................................12
96 8.1. Normative References ......................................12
97 8.2. Informative References ....................................13
98 Acknowledgments ...................................................14
99 Authors' Addresses ................................................15
114Bhargavan, et al. Standards Track [Page 2]
116RFC 7627 TLS Session Hash Extension September 2015
121 In TLS [RFC5246], every session has a "master_secret" computed as:
123 master_secret = PRF(pre_master_secret, "master secret",
124 ClientHello.random + ServerHello.random)
127 where the "pre_master_secret" is the result of some key exchange
128 protocol. For example, when the handshake uses an RSA ciphersuite,
129 this value is generated uniformly at random by the client, whereas
130 for Ephemeral Diffie-Hellman (DHE) ciphersuites, it is the result of
131 a Diffie-Hellman key agreement.
133 As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,
134 an active attacker can synchronize two TLS sessions so that they
135 share the same "master_secret". For an RSA key exchange where the
136 client is unauthenticated, this is achieved as follows. Suppose a
137 client C connects to a server A. C does not realize that A is
138 malicious and that A connects in the background to an honest server S
139 and completes both handshakes. For simplicity, assume that C and S
140 only use RSA ciphersuites.
142 1. C sends a "ClientHello" to A, and A forwards it to S.
144 2. S sends a "ServerHello" to A, and A forwards it to C.
146 3. S sends a "Certificate", containing its certificate chain, to A.
147 A replaces it with its own certificate chain and sends it to C.
149 4. S sends a "ServerHelloDone" to A, and A forwards it to C.
151 5. C sends a "ClientKeyExchange" to A, containing the
152 "pre_master_secret", encrypted with A's public key. A decrypts
153 the "pre_master_secret", re-encrypts it with S's public key, and
156 6. C sends a "Finished" to A. A computes a "Finished" for its
157 connection with S and sends it to S.
159 7. S sends a "Finished" to A. A computes a "Finished" for its
160 connection with C and sends it to C.
162 At this point, both connections (between C and A, and between A and
163 S) have new sessions that share the same "pre_master_secret",
164 "ClientHello.random", "ServerHello.random", as well as other session
165 parameters, including the session identifier and, optionally, the
166 session ticket. Hence, the "master_secret" value will be equal for
170Bhargavan, et al. Standards Track [Page 3]
172RFC 7627 TLS Session Hash Extension September 2015
175 the two sessions and will be associated both at C and S with the same
176 session ID, even though the server identities on the two connections
177 are different. Recall that C only sees A's certificate and is
178 unaware of A's connection with S. Moreover, the record keys on the
179 two connections will also be the same.
181 The scenario above shows that TLS does not guarantee that the master
182 secrets and keys used on different connections will be different.
183 Even if client authentication is used, the scenario still works,
184 except that the two sessions now differ on both client and server
187 A similar scenario can be achieved when the handshake uses a DHE
188 ciphersuite. Note that even if the client or server does not prefer
189 using RSA or DHE, the attacker can force them to use it by offering
190 only RSA or DHE in its hello messages. Handshakes using Ephemeral
191 Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also
192 vulnerable if they allow arbitrary explicit curves or use curves with
193 small subgroups. Against more powerful adversaries, other key
194 exchanges, such as Secure Remote Password (SRP) and Pre-Shared Key
195 (PSK), have also been shown to be vulnerable [VERIFIED-BINDINGS].
197 Once A has synchronized the two connections, since the keys are the
198 same on the two sides, it can step away and transparently forward
199 messages between C and S, reading and modifying when it desires. In
200 the key exchange literature, such occurrences are called unknown key-
201 share attacks, since C and S share a secret but they both think that
202 their secret is shared only with A. In themselves, these attacks do
203 not break integrity or confidentiality between honest parties, but
204 they offer a useful starting point from which to mount impersonation
207 Suppose C tries to resume its session on a new connection with A. A
208 can then resume its session with S on a new connection and forward
209 the abbreviated handshake messages unchanged between C and S. Since
210 the abbreviated handshake only relies on the master secret for
211 authentication and does not mention client or server identities, both
212 handshakes complete successfully, resulting in the same session keys
213 and the same handshake log. A still knows the connection keys and
214 can send messages to both C and S.
216 Critically, at the new connection, even the handshake log is the same
217 on C and S, thus defeating any man-in-the-middle protection scheme
218 that relies on the uniqueness of finished messages, such as the
219 secure renegotiation indication extension [RFC5746] or TLS channel
220 bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on
221 such session synchronization attacks. In particular, it describes a
222 man-in-the-middle attack, called the "triple handshake", that
226Bhargavan, et al. Standards Track [Page 4]
228RFC 7627 TLS Session Hash Extension September 2015
231 circumvents the protections of [RFC5746] to break client-
232 authenticated TLS renegotiation after session resumption. Similar
233 attacks apply to application-level authentication mechanisms that
234 rely on channel bindings [RFC5929] or on key material exported from
237 The underlying protocol issue leading to these attacks is that the
238 TLS master secret is not guaranteed to be unique across sessions,
239 since it is not context-bound to the full handshake that generated
240 it. If we fix this problem in the initial master secret computation,
241 then all these attacks can be prevented. This specification
242 introduces a TLS extension that changes the way the "master_secret"
243 value is computed in a full handshake by including the log of the
244 handshake messages, so that different sessions will, by construction,
245 have different master secrets. This prevents the attacks described
246 in [TRIPLE-HS] and documented in Section 2.11 of [RFC7457].
2482. Requirements Notation
250 This document uses the same notation and terminology used in the TLS
251 protocol specification [RFC5246].
253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
255 "OPTIONAL" in this document are to be interpreted as described in RFC
2583. The TLS Session Hash
260 When a full TLS handshake takes place, we define
262 session_hash = Hash(handshake_messages)
264 where "handshake_messages" refers to all handshake messages sent or
265 received, starting at the ClientHello up to and including the
266 ClientKeyExchange message, including the type and length fields of
267 the handshake messages. This is the concatenation of all the
268 exchanged Handshake structures, as defined in Section 7.4 of
271 For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9
272 of [RFC5246] for the Finished message computation. For all previous
273 versions of TLS, the "Hash" function computes the concatenation of
276 There is no "session_hash" for resumed handshakes, as they do not
277 lead to the creation of a new session.
282Bhargavan, et al. Standards Track [Page 5]
284RFC 7627 TLS Session Hash Extension September 2015
2874. The Extended Master Secret
289 When the extended master secret extension is negotiated in a full
290 handshake, the "master_secret" is computed as
292 master_secret = PRF(pre_master_secret, "extended master secret",
296 The extended master secret computation differs from that described in
297 [RFC5246] in the following ways:
299 o The "extended master secret" label is used instead of "master
302 o The "session_hash" is used instead of the "ClientHello.random" and
303 "ServerHello.random".
305 The "session_hash" depends upon a handshake log that includes
306 "ClientHello.random" and "ServerHello.random", in addition to
307 ciphersuites, key exchange information, and certificates (if any)
308 from the client and server. Consequently, the extended master secret
309 depends upon the choice of all these session parameters.
311 This design reflects the recommendation that keys should be bound to
312 the security contexts that compute them [SP800-108]. The technique
313 of mixing a hash of the key exchange messages into master key
314 derivation is already used in other well-known protocols such as
315 Secure Shell (SSH) [RFC4251].
317 Clients and servers SHOULD NOT accept handshakes that do not use the
318 extended master secret, especially if they rely on features like
319 compound authentication that fall into the vulnerable cases described
3225. Extension Negotiation
3245.1. Extension Definition
326 This document defines a new TLS extension, "extended_master_secret"
327 (with extension type 0x0017), which is used to signal both client and
328 server to use the extended master secret computation. The
329 "extension_data" field of this extension is empty. Thus, the entire
330 encoding of the extension is 00 17 00 00 (in hexadecimal.)
332 Although this document refers only to TLS, the extension proposed
333 here can also be used with Datagram TLS (DTLS) [RFC6347].
338Bhargavan, et al. Standards Track [Page 6]
340RFC 7627 TLS Session Hash Extension September 2015
343 If the client and server agree on this extension and a full handshake
344 takes place, both client and server MUST use the extended master
345 secret derivation algorithm, as defined in Section 4. All other
346 cryptographic computations remain unchanged.
3485.2. Client and Server Behavior: Full Handshake
350 In the following, we use the phrase "abort the handshake" as
351 shorthand for terminating the handshake by sending a fatal
352 "handshake_failure" alert.
354 In all handshakes, a client implementing this document MUST send the
355 "extended_master_secret" extension in its ClientHello.
357 If a server implementing this document receives the
358 "extended_master_secret" extension, it MUST include the extension in
359 its ServerHello message.
361 If both the ClientHello and ServerHello contain the extension, the
362 new session uses the extended master secret computation.
364 If the server receives a ClientHello without the extension, it SHOULD
365 abort the handshake if it does not wish to interoperate with legacy
366 clients. If it chooses to continue the handshake, then it MUST NOT
367 include the extension in the ServerHello.
369 If a client receives a ServerHello without the extension, it SHOULD
370 abort the handshake if it does not wish to interoperate with legacy
373 If the client and server choose to continue a full handshake without
374 the extension, they MUST use the standard master secret derivation
375 for the new session. In this case, the new session is not protected
376 by the mechanisms described in this document. So, implementers
377 should follow the guidelines in Section 5.4 to avoid dangerous usage
378 scenarios. In particular, the master secret derived from the new
379 session should not be used for application-level authentication.
3815.3. Client and Server Behavior: Abbreviated Handshake
383 The client SHOULD NOT offer an abbreviated handshake to resume a
384 session that does not use an extended master secret. Instead, it
385 SHOULD offer a full handshake.
387 If the client chooses to offer an abbreviated handshake even for such
388 sessions in order to support legacy insecure resumption, then the
389 current connection is not protected by the mechanisms in this
390 document. So, the client should follow the guidelines in Section 5.4
394Bhargavan, et al. Standards Track [Page 7]
396RFC 7627 TLS Session Hash Extension September 2015
399 to avoid dangerous usage scenarios. In particular, renegotiation is
400 no longer secure on this connection, even if the client and server
401 support the renegotiation indication extension [RFC5746].
403 When offering an abbreviated handshake, the client MUST send the
404 "extended_master_secret" extension in its ClientHello.
406 If a server receives a ClientHello for an abbreviated handshake
407 offering to resume a known previous session, it behaves as follows:
409 o If the original session did not use the "extended_master_secret"
410 extension but the new ClientHello contains the extension, then the
411 server MUST NOT perform the abbreviated handshake. Instead, it
412 SHOULD continue with a full handshake (as described in
413 Section 5.2) to negotiate a new session.
415 o If the original session used the "extended_master_secret"
416 extension but the new ClientHello does not contain it, the server
417 MUST abort the abbreviated handshake.
419 o If neither the original session nor the new ClientHello uses the
420 extension, the server SHOULD abort the handshake. If it continues
421 with an abbreviated handshake in order to support legacy insecure
422 resumption, the connection is no longer protected by the
423 mechanisms in this document, and the server should follow the
424 guidelines in Section 5.4.
426 o If the new ClientHello contains the extension and the server
427 chooses to continue the handshake, then the server MUST include
428 the "extended_master_secret" extension in its ServerHello message.
430 If a client receives a ServerHello that accepts an abbreviated
431 handshake, it behaves as follows:
433 o If the original session did not use the "extended_master_secret"
434 extension but the new ServerHello contains the extension, the
435 client MUST abort the handshake.
437 o If the original session used the extension but the new ServerHello
438 does not contain the extension, the client MUST abort the
441 If the client and server continue the abbreviated handshake, they
442 derive the connection keys for the new session as usual from the
443 master secret of the original session.
450Bhargavan, et al. Standards Track [Page 8]
452RFC 7627 TLS Session Hash Extension September 2015
4555.4. Interoperability Considerations
457 To allow interoperability with legacy clients and servers, a TLS peer
458 may decide to accept full handshakes that use the legacy master
459 secret computation. If so, they need to differentiate between
460 sessions that use legacy and extended master secrets by adding a flag
461 to the session state.
463 If a client or server chooses to continue with a full handshake
464 without the extended master secret extension, then the new session
465 becomes vulnerable to the man-in-the-middle key synchronization
466 attack described in Section 1. Hence, the client or server MUST NOT
467 export any key material based on the new master secret for any
468 subsequent application-level authentication. In particular, it MUST
469 disable [RFC5705] and any Extensible Authentication Protocol (EAP)
470 relying on compound authentication [COMPOUND-AUTH].
472 If a client or server chooses to continue an abbreviated handshake to
473 resume a session that does not use the extended master secret, then
474 the current connection becomes vulnerable to a man-in-the-middle
475 handshake log synchronization attack as described in Section 1.
476 Hence, the client or server MUST NOT use the current handshake's
477 "verify_data" for application-level authentication. In particular,
478 the client MUST disable renegotiation and any use of the "tls-unique"
479 channel binding [RFC5929] on the current connection.
481 If the original session uses an extended master secret but the
482 ClientHello or ServerHello in the abbreviated handshake does not
483 include the extension, it MAY be safe to continue the abbreviated
484 handshake since it is protected by the extended master secret of the
485 original session. This scenario may occur, for example, when a
486 server that implements this extension establishes a session but the
487 session is subsequently resumed at a different server that does not
488 support the extension. Since such situations are unusual and likely
489 to be the result of transient or inadvertent misconfigurations, this
490 document recommends that the client and server MUST abort such
4936. Security Considerations
4956.1. Triple Handshake Preconditions and Impact
497 One way to mount a triple handshake attack is described in Section 1,
498 along with a mention of the security mechanisms that break due to the
499 attack; more in-depth discussion and diagrams can be found in
500 [TRIPLE-HS]. Here, some further discussion is presented about attack
501 preconditions and impact.
506Bhargavan, et al. Standards Track [Page 9]
508RFC 7627 TLS Session Hash Extension September 2015
511 To mount a triple handshake attack, it must be possible to force the
512 same master secret on two different sessions. For this to happen,
513 two preconditions must be met:
515 o The client, C, must be willing to connect to a malicious server,
516 A. In certain contexts, like the web, this can be easily
517 achieved, since a browser can be instructed to load content from
520 o The pre-master secret must be synchronized on the two sessions.
521 This is particularly easy to achieve with the RSA and DHE key
522 exchanges, but under some conditions, ECDHE, SRP, and PSK key
523 exchanges can be exploited to this effect as well.
525 Once the master secret is synchronized on two sessions, any security
526 property that relies on the uniqueness of the master secret is
527 compromised. For example, a TLS exporter [RFC5705] no longer
528 provides a unique key bound to the current session.
530 TLS session resumption also relies on the uniqueness of the master
531 secret to authenticate the resuming peers. Hence, if a synchronized
532 session is resumed, the peers cannot be sure about each other's
533 identities, and the attacker knows the connection keys. Clearly, a
534 precondition to this step of the attack is that both client and
535 server support session resumption (either via session identifier or
536 session tickets [RFC5077]).
538 Additionally, in a synchronized abbreviated handshake, the whole
539 transcript (which includes the "verify_data" values) is synchronized.
540 So, after an abbreviated handshake, channel bindings like
541 "tls-unique" [RFC5929] will not uniquely identify the connection
544 Synchronization of the "verify_data" in abbreviated handshakes also
545 undermines the security guarantees of the renegotiation indication
546 extension [RFC5746], re-enabling a prefix-injection flaw similar to
547 the renegotiation attack [Ray09]. However, in a triple handshake
548 attack, the client sees the server certificate changing across
549 different full handshakes. Hence, a precondition to mount this stage
550 of the attack is that the client accepts different certificates at
551 each handshake, even if their common names do not match. Before the
552 triple handshake attack was discovered, this used to be widespread
553 behavior, at least among some web browsers; such browsers were hence
554 vulnerable to the attack.
556 The extended master secret extension thwarts triple handshake attacks
557 at their first stage by ensuring that different sessions necessarily
558 end up with different master secret values. Hence, all security
562Bhargavan, et al. Standards Track [Page 10]
564RFC 7627 TLS Session Hash Extension September 2015
567 properties relying on the uniqueness of the master secret are now
568 expected to hold. In particular, if a TLS session is protected by
569 the extended master secret extension, it is safe to resume it, to use
570 its channel bindings, and to allow for certificate changes across
571 renegotiation, meaning that all certificates are controlled by the
572 same peer. A symbolic cryptographic protocol analysis justifying the
573 extended master secret extension appears in [VERIFIED-BINDINGS].
5756.2. Cryptographic Properties of the Hash Function
577 The session hashes of two different sessions need to be distinct;
578 hence, the "Hash" function used to compute the "session_hash" needs
579 to be collision resistant. As such, hash functions such as MD5 or
580 SHA1 are NOT RECOMMENDED.
582 We observe that the "Hash" function used in the Finished message
583 computation already needs to be collision resistant for the
584 renegotiation indication extension [RFC5746] to work, because a
585 meaningful collision on the handshake messages (and hence on the
586 "verify_data") may re-enable the renegotiation attack [Ray09].
588 The hash function used to compute the session hash depends on the TLS
589 protocol version. All current ciphersuites defined for TLS 1.2 use
590 SHA256 or better, and so does the session hash. For earlier versions
591 of the protocol, only MD5 and SHA1 can be assumed to be supported,
592 and this document does not require legacy implementations to add
593 support for new hash functions. In these versions, the session hash
594 uses the concatenation of MD5 and SHA1, as in the Finished message.
5966.3. Handshake Messages Included in the Session Hash
598 The "session_hash" is intended to encompass all relevant session
599 information, including ciphersuite negotiation, key exchange
600 messages, and client and server identities. The hash is needed to
601 compute the extended master secret and hence must be available before
602 the Finished messages.
604 This document sets the "session_hash" to cover all handshake messages
605 up to and including the ClientKeyExchange. For existing TLS
606 ciphersuites, these messages include all the significant contents of
607 the new session -- CertificateVerify does not change the session
608 content. At the same time, this allows the extended master secret to
609 be computed immediately after the pre-master secret, so that
610 implementations can shred the temporary pre-master secret from memory
611 as early as possible.
618Bhargavan, et al. Standards Track [Page 11]
620RFC 7627 TLS Session Hash Extension September 2015
623 It is possible that new ciphersuites or TLS extensions may include
624 additional messages between ClientKeyExchange and Finished that add
625 important session context. In such cases, some of the security
626 guarantees of this specification may no longer apply, and new man-in-
627 the-middle attacks may be possible. For example, if the client and
628 server support the session ticket extension [RFC5077], the session
629 hash does not cover the new session ticket sent by the server.
630 Hence, a man-in-the-middle may be able to cause a client to store a
631 session ticket that was not meant for the current session. Attacks
632 based on this vector are not yet known, but applications that store
633 additional information in session tickets beyond those covered in the
634 session hash require careful analysis.
6366.4. No SSL 3.0 Support
638 The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a
639 predecessor of the TLS protocol, and it is equally vulnerable to
640 triple handshake attacks, alongside other vulnerabilities stemming
641 from its use of obsolete cryptographic constructions that are now
642 considered weak. SSL 3.0 has been deprecated [RFC7568].
644 The countermeasure described in this document relies on a TLS
645 extension and hence cannot be used with SSL 3.0. Clients and servers
646 implementing this document SHOULD refuse SSL 3.0 handshakes. If they
647 choose to support SSL 3.0, the resulting sessions MUST use the legacy
648 master secret computation, and the interoperability considerations of
6517. IANA Considerations
653 IANA has added the extension code point 23 (0x0017), which has been
654 used by prototype implementations, for the "extended_master_secret"
655 extension to the "ExtensionType Values" registry specified in the TLS
656 specification [RFC5246].
6608.1. Normative References
662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
663 Requirement Levels", BCP 14, RFC 2119,
664 DOI 10.17487/RFC2119, March 1997,
665 <http://www.rfc-editor.org/info/rfc2119>.
667 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
668 (TLS) Protocol Version 1.2", RFC 5246,
669 DOI 10.17487/RFC5246, August 2008,
670 <http://www.rfc-editor.org/info/rfc5246>.
674Bhargavan, et al. Standards Track [Page 12]
676RFC 7627 TLS Session Hash Extension September 2015
6798.2. Informative References
682 Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the-
683 Middle in Tunnelled Authentication Protocols", Security
684 Protocols, LNCS, Volume 3364, DOI 10.1007/11542322_6,
687 [Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.
689 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
690 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
691 January 2006, <http://www.rfc-editor.org/info/rfc4251>.
693 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
694 "Transport Layer Security (TLS) Session Resumption
695 without Server-Side State", RFC 5077,
696 DOI 10.17487/RFC5077, January 2008,
697 <http://www.rfc-editor.org/info/rfc5077>.
699 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
700 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
701 March 2010, <http://www.rfc-editor.org/info/rfc5705>.
703 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
704 "Transport Layer Security (TLS) Renegotiation Indication
705 Extension", RFC 5746, DOI 10.17487/RFC5746, February
706 2010, <http://www.rfc-editor.org/info/rfc5746>.
708 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
709 for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
710 <http://www.rfc-editor.org/info/rfc5929>.
712 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
713 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
714 DOI 10.17487/RFC6101, August 2011,
715 <http://www.rfc-editor.org/info/rfc6101>.
717 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
718 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
719 January 2012, <http://www.rfc-editor.org/info/rfc6347>.
721 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
722 Known Attacks on Transport Layer Security (TLS) and
723 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
724 February 2015, <http://www.rfc-editor.org/info/rfc7457>.
730Bhargavan, et al. Standards Track [Page 13]
732RFC 7627 TLS Session Hash Extension September 2015
735 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
736 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
737 DOI 10.17487/RFC7568, June 2015,
738 <http://www.rfc-editor.org/info/rfc7568>.
740 [SP800-108] Chen, L., "Recommendation for Key Derivation Using
741 Pseudorandom Functions (Revised)", NIST Special
742 Publication 800-108, 2009.
744 [TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
745 A., and P-Y. Strub, "Triple Handshakes and Cookie
746 Cutters: Breaking and Fixing Authentication over TLS",
747 IEEE Symposium on Security and Privacy,
748 DOI 10.1109/SP.2014.14, 2014.
751 Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
752 "Verified Contributive Channel Bindings for Compound
753 Authentication", Network and Distributed System Security
754 Symposium (NDSS), 2015.
758 Triple handshake attacks were originally discovered by Antoine
759 Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti. They
760 were further developed by the miTLS team: Cedric Fournet, Pierre-Yves
761 Strub, Markulf Kohlweiss, and Santiago Zanella-Beguelin. Many of the
762 ideas in this document emerged from discussions with Martin Abadi,
763 Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric
764 Rescorla, Martin Rex, and Brian Smith.
786Bhargavan, et al. Standards Track [Page 14]
788RFC 7627 TLS Session Hash Extension September 2015
793 Karthikeyan Bhargavan (editor)
794 Inria Paris-Rocquencourt
799 Email: karthikeyan.bhargavan@inria.fr
802 Antoine Delignat-Lavaud
803 Inria Paris-Rocquencourt
808 Email: antoine.delignat-lavaud@inria.fr
812 Inria Paris-Rocquencourt
817 Email: alfredo.pironti@inria.fr
822 1600 Amphitheatre Parkway
823 Mountain View, CA 94043
826 Email: agl@google.com
835 Email: maray@microsoft.com
842Bhargavan, et al. Standards Track [Page 15]