draft-ietf-tls-falsestart-01.txt   draft-ietf-tls-falsestart-02.txt 
TLS Working Group A. Langley TLS Working Group A. Langley
Internet-Draft N. Modadugu Internet-Draft N. Modadugu
Intended status: Experimental B. Moeller Intended status: Experimental B. Moeller
Expires: May 5, 2016 Google Expires: November 12, 2016 Google
November 2, 2015 May 11, 2016
Transport Layer Security (TLS) False Start Transport Layer Security (TLS) False Start
draft-ietf-tls-falsestart-01 draft-ietf-tls-falsestart-02
Abstract Abstract
This document specifies an optional behavior of TLS client This document specifies an optional behavior of TLS client
implementations, dubbed False Start. It affects only protocol implementations, dubbed False Start. It affects only protocol
timing, not on-the-wire protocol data, and can be implemented timing, not on-the-wire protocol data, and can be implemented
unilaterally. A TLS False Start reduces handshake latency to one unilaterally. A TLS False Start reduces handshake latency to one
round trip. round trip.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2016. This Internet-Draft will expire on November 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. 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 [RFC2616]. data first, such as HTTP [RFC7230].
Client Server Client Server
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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 having updated its TLS Record Protocol write state as (thus having updated its TLS Record Protocol write state as
negotiated in the handshake), but has yet to receive the server's negotiated in the handshake), but has yet to receive the server's
"ChangeCipherSpec" and "Finished" messages. (By section 7.4.9 of "ChangeCipherSpec" and "Finished" messages. (By section 7.4.9 of
[RFC5246], after a full handshake, the client would have to delay [RFC5246], after a full handshake, the client would have to delay
sending application data until it has received and validated the sending application data until it has received and validated the
server's "Finished" message.) Accordingly, the latency penalty for server's "Finished" message.) Accordingly, the latency penalty for
using TLS with HTTP can be kept at one round-trip time. using TLS with HTTP can be kept at one round-trip time.
(Note that in practice, the TCP three-way handshake [RFC0793]
typically adds one round-trip time before the client can even send
the ClientHello. See [RFC7413] for a latency improvement at that
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.
skipping to change at page 9, line 18 skipping to change at page 9, line 22
[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. August 2008.
[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. August 2008.
8.2. Informative References 8.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 793, DOI 10.17487/RFC0793, September 1981,
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. <http://www.rfc-editor.org/info/rfc793>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<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, April 2015.
[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-10, Version 1.3", Work in Progress, draft-ietf-tls-tls13-12,
October 2015. March 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
 End of changes. 9 change blocks. 
12 lines changed or deleted 26 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/