draft-ietf-tls-falsestart-02.txt   rfc7918.txt 
TLS Working Group A. Langley Internet Engineering Task Force (IETF) A. Langley
Internet-Draft N. Modadugu Request for Comments: 7918 N. Modadugu
Intended status: Experimental B. Moeller Category: Informational B. Moeller
Expires: November 12, 2016 Google ISSN: 2070-1721 Google
May 11, 2016 August 2016
Transport Layer Security (TLS) False Start Transport Layer Security (TLS) False Start
draft-ietf-tls-falsestart-02
Abstract Abstract
This document specifies an optional behavior of TLS client This document specifies an optional behavior of Transport Layer
implementations, dubbed False Start. It affects only protocol Security (TLS) client implementations, dubbed "False Start". It
timing, not on-the-wire protocol data, and can be implemented affects only protocol timing, not on-the-wire protocol data, and can
unilaterally. A TLS False Start reduces handshake latency to one be implemented unilaterally. A TLS False Start reduces handshake
round trip. latency to one round trip.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 12, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7918.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. False Start Compatibility . . . . . . . . . . . . . . . . . . 4 3. False Start Compatibility . . . . . . . . . . . . . . . . . . 4
4. Client-side False Start . . . . . . . . . . . . . . . . . . . 4 4. Client-Side False Start . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 6 5.1. Symmetric Cipher . . . . . . . . . . . . . . . . . . . . 6
5.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 7 5.2. Protocol Version . . . . . . . . . . . . . . . . . . . . 7
5.3. Key Exchange and Client Certificate Type . . . . . . . . 7 5.3. Key Exchange and Client Certificate Type . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 1. Introduction
A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246] A full handshake in TLS protocol versions up to TLS 1.2 [RFC5246]
requires two full protocol rounds (four flights) before the handshake requires two full protocol rounds (four flights) before the handshake
is complete and the protocol parties may begin to send application is complete and the protocol parties may begin to send application
data. Thus, using TLS can add a latency penalty of two network data. Thus, using TLS can add a latency penalty of two network
round-trip times for application protocols in which the client sends round-trip times for application protocols in which the client sends
data first, such as HTTP [RFC7230]. data first, such as HTTP [RFC7230]. Figure 1 (copied from [RFC5246])
shows the message flow for a full handshake.
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1 [RFC5246]. Message flow for a full handshake Figure 1: Message Flow for a Full Handshake
This document describes a technique that alleviates the latency This document describes a technique that alleviates the latency
burden imposed by TLS: the client-side TLS False Start. If certain burden imposed by TLS: the client-side TLS False Start. If certain
conditions are met, the client can start to send application data conditions are met, the client can start to send application data
when the full handshake is only partially complete, namely, when the when the full handshake is only partially complete, namely, when the
client has sent its own "ChangeCipherSpec" and "Finished" messages client has sent its own ChangeCipherSpec and Finished messages (thus
(thus having updated its TLS Record Protocol write state as having updated its TLS Record Protocol write state as negotiated in
negotiated in the handshake), but has yet to receive the server's the handshake) but has yet to receive the server's ChangeCipherSpec
"ChangeCipherSpec" and "Finished" messages. (By section 7.4.9 of and Finished messages. (Per Section 7.4.9 of [RFC5246], after a full
[RFC5246], after a full handshake, the client would have to delay handshake, the client would have to delay sending application data
sending application data until it has received and validated the until it has received and validated the server's Finished message.)
server's "Finished" message.) Accordingly, the latency penalty for Accordingly, the latency penalty for using TLS with HTTP can be kept
using TLS with HTTP can be kept at one round-trip time. at one round-trip time.
(Note that in practice, the TCP three-way handshake [RFC0793] Note that in practice, the TCP three-way handshake [RFC0793]
typically adds one round-trip time before the client can even send typically adds one round-trip time before the client can even send
the ClientHello. See [RFC7413] for a latency improvement at that the ClientHello. See [RFC7413] for a latency improvement at that
level.) level.
When an earlier TLS session is resumed, TLS uses an abbreviated When an earlier TLS session is resumed, TLS uses an abbreviated
handshake with only three protocol flights. For application handshake with only three protocol flights. For application
protocols in which the client sends data first, this abbreviated protocols in which the client sends data first, this abbreviated
handshake adds just one round-trip time to begin with, so there is no handshake adds just one round-trip time to begin with, so there is no
need for a client-side False Start. However, if the server sends need for a client-side False Start. However, if the server sends
application data first, the abbreviated handshake adds two round-trip application data first, the abbreviated handshake adds two round-trip
times, and this could be reduced to just one added round-trip time by times, and this could be reduced to just one added round-trip time by
doing a server-side False Start. There is little need for this in doing a server-side False Start. There is little need for this in
practice, so this document does not consider server-side False Starts practice, so this document does not consider server-side False Starts
further. further.
Note also that TLS versions 1.3 [tls13] and beyond are out of scope Note also that TLS versions 1.3 [TLS13] and beyond are out of scope
for this document. False Start will not be needed with these newer for this document. False Start will not be needed with these newer
versions since protocol flows minimizing the number of round trips versions since protocol flows minimizing the number of round trips
have become a first-order design goal. have become a first-order design goal.
In a False Start, when the client sends application data before it In a False Start, when the client sends application data before it
has received and verified the server's "Finished" message, there are has received and verified the server's Finished message, there are
two possible outcomes: two possible outcomes:
o The handshake completes successfully: Once both "Finished" o The handshake completes successfully: The handshake is
messages have been received and verified, this retroactively retroactively validated when both Finished messages have been
validates the handshake. In this case, the transcript of protocol received and verified. This retroactively validates the
data carried over the transport underlying TLS will look as usual, handshake. In this case, the transcript of protocol data carried
apart from the different timing. over the transport underlying TLS will look as usual, apart from
the different timing.
o The handshake fails: If a party does not receive the other side's o The handshake fails: If a party does not receive the other side's
"Finished" message, or if the "Finished" message's contents are Finished message or if the Finished message's contents are not
not correct, the handshake never gets validated. This means that correct, the handshake never gets validated. This means that an
an attacker may have removed, changed, or injected handshake attacker may have removed, changed, or injected handshake
messages. In this case, data has been sent over the underlying messages. In this case, data has been sent over the underlying
transport that would not have been sent without the False Start. transport that would not have been sent without the False Start.
The latter scenario makes it necessary to restrict when a False Start The latter scenario makes it necessary to restrict when a False Start
is allowed, as described in this document. Section 3 considers basic is allowed, as described in this document. Section 3 considers basic
requirements for using False Start. Section 4 specifies the behavior requirements for using False Start. Section 4 specifies the behavior
for clients, referring to important security considerations in for clients, referring to important security considerations in
Section 5. Section 5.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT","RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. False Start Compatibility 3. False Start Compatibility
TLS False Start as described in detail in the subsequent sections, if TLS False Start as described in detail in the subsequent sections, if
implemented, is an optional feature. implemented, is an optional feature.
A TLS server implementation is defined to be "False Start compatible" A TLS server implementation is defined to be "False Start compatible"
if it tolerates receiving TLS records on the transport connection if it tolerates receiving TLS records on the transport connection
early, before the protocol has reached the state to process these. early, before the protocol has reached the state to process them.
For successful use of client-side False Start in a TLS connection, For successful use of client-side False Start in a TLS connection,
the server has to be False Start compatible. Out-of-band knowledge the server has to be False Start compatible. Out-of-band knowledge
that the server is False Start compatible may be available, e.g. if that the server is False Start compatible may be available, e.g., if
this is mandated by specific application profile standards. As this is mandated by specific application profile standards. As
discussed in Appendix A, the requirement for False Start discussed in Appendix A, the requirement for False Start
compatibility does generally not pose a hindrance in practice. compatibility generally does not pose a hindrance in practice.
4. Client-side False Start 4. Client-Side False Start
This section specifies a change to the behavior of TLS client This section specifies a change to the behavior of TLS client
implementations in full TLS handshakes. implementations in full TLS handshakes.
When the client has sent its "ChangeCipherSpec" and "Finished" When the client has sent its ChangeCipherSpec and Finished messages,
messages, its default behavior following [RFC5246] is to not send its default behavior per [RFC5246] is to not send application data
application data until it has received the server's until it has received the server's ChangeCipherSpec and Finished
"ChangeCipherSpec" and "Finished" messages, which completes the messages, which completes the handshake. With the False Start
handshake. With the False Start protocol modification, the client protocol modification, the client MAY send application data earlier
MAY send application data earlier (under the new Cipher Spec) if each (under the new Cipher Spec) if each of the following conditions is
of the following conditions is satisfied: satisfied:
o The application layer has requested the TLS False Start option. o The application layer has requested the TLS False Start option.
o The symmetric cipher defined by the cipher suite negotiated in o The symmetric cipher defined by the cipher suite negotiated in
this handshake has been whitelisted for use with False Start this handshake has been whitelisted for use with False Start
according to the Security Considerations in Section 5.1. according to the Security Considerations in Section 5.1.
o The protocol version chosen by ServerHello.server_version has been o The protocol version chosen by ServerHello.server_version has been
whitelisted for use with False Start according to the Security whitelisted for use with False Start according to the Security
Considerations in Section 5.2. Considerations in Section 5.2.
skipping to change at page 5, line 45 skipping to change at page 5, line 35
authenticated server until all handshake messages have been received. authenticated server until all handshake messages have been received.
With False Start, unlike with the default handshake behavior, With False Start, unlike with the default handshake behavior,
applications are able to send data before this point has been applications are able to send data before this point has been
reached: from an application point of view, being able to send data reached: from an application point of view, being able to send data
does not imply that an authenticated peer is present. Accordingly, does not imply that an authenticated peer is present. Accordingly,
it is recommended that TLS implementations allow the application it is recommended that TLS implementations allow the application
layer to query whether the handshake has completed. layer to query whether the handshake has completed.
5. Security Considerations 5. Security Considerations
In a TLS handshake, the "Finished" messages serve to validate the In a TLS handshake, the Finished messages serve to validate the
entire handshake. These messages are based on a hash of the entire handshake. These messages are based on a hash of the
handshake so far processed by a PRF keyed with the new master secret handshake so far processed by a Pseudorandom Function (PRF) keyed
(serving as a MAC), and are also sent under the new Cipher Spec with with the new master secret (serving as a Message Authentication Code
its keyed MAC, where the MAC key again is derived from the master (MAC)) and are also sent under the new Cipher Spec with its keyed
secret. The protocol design relies on the assumption that any server MAC, where the MAC key again is derived from the master secret. The
and/or client authentication done during the handshake carries over protocol design relies on the assumption that any server and/or
to this. While an attacker could, for example, have changed the client authentication done during the handshake carries over to this.
cipher suite list sent by the client to the server and thus While an attacker could, for example, have changed the cipher suite
influenced cipher suite selection (presumably towards a less secure list sent by the client to the server and thus influenced cipher
choice) or could have made other modifications to handshake messages suite selection (presumably towards a less secure choice) or could
in transmission, the attacker would not be able to round off the have made other modifications to handshake messages in transmission,
modified handshake with a valid "Finished" message: every TLS cipher the attacker would not be able to round off the modified handshake
suite is presumed to key the PRF appropriately to ensure with a valid Finished message: every TLS cipher suite is presumed to
unforgeability. Once the handshake has been validated by verifying key the PRF appropriately to ensure unforgeability. Verifying the
the "Finished" messages, this confirms that the handshake has not Finished messages validates the handshake and confirms that the
been tampered with, thus bootstrapping secure encryption (using handshake has not been tampered with; thus, secure encryption is
algorithms as negotiated) from secure authentication. bootstrapped from secure authentication.
Using False Start interferes with this approach of bootstrapping Using False Start interferes with this approach of bootstrapping
secure encryption from secure authentication, as application data may secure encryption from secure authentication, as application data may
have already been sent before "Finished" validation confirms that the have already been sent before Finished validation confirms that the
handshake has not been tampered with -- so there is generally no hope handshake has not been tampered with -- so there is generally no way
to be sure that communication with the expected peer is indeed taking to be sure that communication with the expected peer is indeed taking
place during the False Start. Instead, the security goal is to place during the False Start. Instead, the security goal is to
ensure that if anyone at all can decrypt the application data sent in ensure that if anyone at all can decrypt the application data sent in
a False Start, this must be the legitimate peer: while an attacker a False Start, it must be the legitimate peer. While an attacker
could be influencing the handshake (restricting cipher suite could be influencing the handshake (restricting cipher suite
selection, modifying key exchange messages, etc.), the attacker selection, modifying key exchange messages, etc.), the attacker
should not be able to benefit from this. The TLS protocol already should not be able to benefit from this. The TLS protocol already
relies on such a security property for authentication -- with False relies on such a security property for authentication; with False
Start, the same is needed for encryption. This motivates the rules Start, the same is needed for encryption. This motivates the rules
put forth in the following subsections. put forth in the following subsections.
It is prudent for applications to be even more restrictive. If It is prudent for applications to be even more restrictive. If
heuristically a small list of cipher suites and a single protocol heuristically a small list of cipher suites and a single protocol
version is found to be sufficient for the majority of TLS handshakes version is found to be sufficient for the majority of TLS handshakes
in practice, it could make sense to forego False Start for any in practice, it could make sense to forego False Start for any
handshake that does not match this expected pattern, even if there is handshake that does not match this expected pattern, even if there is
no concrete reason to assume a cryptographic weakness. Similarly, if no concrete reason to assume a cryptographic weakness. Similarly, if
handshakes almost always use ephemeral ECDH over one of a few named handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman
curves, it could make sense to disallow False Start with any other (ECDH) over one of a few named curves, it could make sense to
supported curve. disallow False Start with any other supported curve.
5.1. Symmetric Cipher 5.1. Symmetric Cipher
Clients MUST NOT use the False Start protocol modification in a Clients MUST NOT use the False Start protocol modification in a
handshake unless the cipher suite uses a symmetric cipher that is handshake unless the cipher suite uses a symmetric cipher that is
considered cryptographically strong. considered cryptographically strong.
Implementations may have their own classification of ciphers (and may Implementations may have their own classification of ciphers (and may
additionally allow the application layer to provide a additionally allow the application layer to provide a
classification), but generally only symmetric ciphers with an classification), but generally only symmetric ciphers with an
skipping to change at page 7, line 14 skipping to change at page 7, line 7
ciphers specified in [RFC4492] and [RFC5246] can be recommended for ciphers specified in [RFC4492] and [RFC5246] can be recommended for
use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384 use with False Start). The AES_128_GCM_SHA256 or AES_256_GCM_SHA384
ciphers specified in [RFC5288] and [RFC5289] can be considered ciphers specified in [RFC5288] and [RFC5289] can be considered
sufficiently strong for most uses. Implementations that support sufficiently strong for most uses. Implementations that support
additional cipher suites have to be careful to whitelist only additional cipher suites have to be careful to whitelist only
suitable symmetric ciphers; if in doubt, False Start should not be suitable symmetric ciphers; if in doubt, False Start should not be
used with a given symmetric cipher. used with a given symmetric cipher.
While an attacker can change handshake messages to force a downgrade While an attacker can change handshake messages to force a downgrade
to a less secure symmetric cipher than otherwise would have been to a less secure symmetric cipher than otherwise would have been
chosen, this rule ensures that in such a downgrade attack no chosen, this rule ensures that in such a downgrade attack, no
application data will be sent under an insecure symmetric cipher. application data will be sent under an insecure symmetric cipher.
5.2. Protocol Version 5.2. Protocol Version
Clients MUST NOT use the False Start protocol modification in a Clients MUST NOT use the False Start protocol modification in a
handshake unless the protocol version chosen by handshake unless the protocol version chosen by
ServerHello.server_version has been whitelisted for this use. ServerHello.server_version has been whitelisted for this use.
Generally, to avoid potential protocol downgrade attacks, Generally, to avoid potential protocol downgrade attacks,
implementations should whitelist only their latest (highest-valued) implementations should whitelist only their latest (highest-valued)
skipping to change at page 7, line 38 skipping to change at page 7, line 31
The details of nominally identical cipher suites can differ between The details of nominally identical cipher suites can differ between
protocol versions, so this reinforces Section 5.1. protocol versions, so this reinforces Section 5.1.
5.3. Key Exchange and Client Certificate Type 5.3. Key Exchange and Client Certificate Type
Clients MUST NOT use the False Start protocol modification in a Clients MUST NOT use the False Start protocol modification in a
handshake unless the cipher suite uses a key exchange method that has handshake unless the cipher suite uses a key exchange method that has
been whitelisted for this use. Also, clients MUST NOT use the False been whitelisted for this use. Also, clients MUST NOT use the False
Start protocol modification unless any parameters to the key exchange Start protocol modification unless any parameters to the key exchange
methods (such as ServerDHParams, ServerECDHParams) have been methods (such as ServerDHParams or ServerECDHParams) have been
whitelisted for this use. Furthermore, when using client whitelisted for this use. Furthermore, when using client
authentication, clients MUST NOT use the False Start protocol authentication, clients MUST NOT use the False Start protocol
modification unless the client certificate type has been whitelisted modification unless the client certificate type has been whitelisted
for this use. for this use.
Implementations may have their own whitelists of key exchange Implementations may have their own whitelists of key exchange
methods, parameters, and client certificate types (and may methods, parameters, and client certificate types (and may
additionally allow the application layer to specify whitelists). additionally allow the application layer to specify whitelists).
Generally, out of the options from [RFC5246] and [RFC4492], the Generally, out of the options from [RFC5246] and [RFC4492], the
following whitelists are recommended: following whitelists are recommended:
skipping to change at page 8, line 20 skipping to change at page 8, line 12
from [RFC5246] and [RFC4492] does not support any of the above key from [RFC5246] and [RFC4492] does not support any of the above key
exchange methods, all of its supported key exchange methods can be exchange methods, all of its supported key exchange methods can be
whitelisted for False Start use. Care is required with any whitelisted for False Start use. Care is required with any
additional key exchange methods, as these may not have similar additional key exchange methods, as these may not have similar
properties. properties.
The recommended whitelists are such that if cryptographic algorithms The recommended whitelists are such that if cryptographic algorithms
suitable for forward secrecy would possibly be negotiated, no False suitable for forward secrecy would possibly be negotiated, no False
Start will take place if the current handshake fails to provide Start will take place if the current handshake fails to provide
forward secrecy. (Forward secrecy can be achieved using ephemeral forward secrecy. (Forward secrecy can be achieved using ephemeral
Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is Diffie-Hellman or ephemeral Elliptic Curve Diffie-Hellman; there is
no forward secrecy when a using key exchange method of RSA, RSA_PSK, no forward secrecy when using a key exchange method of RSA, RSA_PSK,
DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type
of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.)
As usual, the benefits of forward secrecy may need to be balanced As usual, the benefits of forward secrecy may need to be balanced
against efficiency, and accordingly even implementations that support against efficiency, and accordingly, even implementations that
the above key exchange methods might whitelist further key exchange support the above key exchange methods might whitelist further key
methods and client certificate types. exchange methods and client certificate types.
Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow Client certificate types rsa_sign, dss_sign, and ecdsa_sign do allow
forward security, but using False Start with any of these means forward security, but using False Start with any of these means
sending application data tied to the client's signature before the sending application data tied to the client's signature before the
server's authenticity (and, thus, the CertificateRequest message) has server's authenticity (and thus the CertificateRequest message) has
been completely verified, so these too are not generally suitable for been completely verified, so these too are not generally suitable for
the client certificate type whitelist. the client certificate type whitelist.
6. Acknowledgments 6. References
The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson,
Eric Rescorla, and Brian Smith for their input.
7. IANA Considerations
None.
8. References
8.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. DOI 10.17487/RFC5288, August 2008,
<http://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008. DOI 10.17487/RFC5289, August 2008,
<http://www.rfc-editor.org/info/rfc5289>.
8.2. Informative References 6.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<http://www.rfc-editor.org/info/rfc7413>. <http://www.rfc-editor.org/info/rfc7413>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, April 2015. Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<http://www.rfc-editor.org/info/rfc7507>.
[tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, draft-ietf-tls-tls13-12, Version 1.3", Work in Progress, draft-ietf-tls-tls13-14,
March 2016. July 2016.
Appendix A. Implementation Notes Appendix A. Implementation Notes
TLS False Start is a modification to the TLS protocol, and some TLS False Start is a modification to the TLS protocol, and some
implementations that conform to [RFC5246] may have problems implementations that conform to [RFC5246] may have problems
interacting with implementations that use the False Start interacting with implementations that use the False Start
modification. If the peer uses a False Start, application data modification. If the peer uses a False Start, application data
records may be received directly following the peer's "Finished" records may be received directly following the peer's Finished
message, before the TLS implementation has sent its own "Finished" message, before the TLS implementation has sent its own Finished
message. False Start compatibility as defined in Section 3 ensures message. False Start compatibility as defined in Section 3 ensures
that these records with application data will simply remain buffered that these records with application data will simply remain buffered
for later processing. for later processing.
A False Start compatible TLS implementation does not have to be aware A False Start compatible TLS implementation does not have to be aware
of the False Start concept, and is certainly not expected to detect of the False Start concept and is certainly not expected to detect
whether a False Start handshake is currently taking place: thanks to whether a False Start handshake is currently taking place: thanks to
transport layer buffering, typical implementations will be False transport layer buffering, typical implementations will be False
Start compatible without having been designed for it. Start compatible without having been designed for it.
Acknowledgments
The authors wish to thank Wan-Teh Chang, Ben Laurie, Martin Thomson,
Eric Rescorla, and Brian Smith for their input.
Authors' Addresses Authors' Addresses
Adam Langley Adam Langley
Google Inc. Google Inc.
345 Spear St 345 Spear St
San Francisco, CA 94105 San Francisco, CA 94105
USA United States of America
Email: agl@google.com Email: agl@google.com
Nagendra Modadugu Nagendra Modadugu
Google Inc. Google Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: nagendra@cs.stanford.edu Email: nagendra@cs.stanford.edu
Bodo Moeller Bodo Moeller
Google Switzerland GmbH Google Switzerland GmbH
Brandschenkestrasse 110 Brandschenkestrasse 110
Zurich 8002 Zurich 8002
Switzerland Switzerland
Email: bmoeller@acm.org Email: bmoeller@acm.org
 End of changes. 53 change blocks. 
135 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/