| < 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||