TLS Working Group V. Krasnov Internet-Draft CloudFlare Inc. Intended status: Informational May 13, 2015 Expires: November 14, 2015 Transport Layer Security (TLS) Jump Start draft-vkrasnov-tls-jumpstart-00 Abstract This document specifies an optional behavior of TLS implementation called Jump Start. It alters the way the initial Client and Server handshake messages reach their destination, but not the protocol data, and can be implemented unilaterally. The TLS Jump Start feature leads to a latency reduction of one round trip for all handshakes (on average). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 14, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Krasnov Expires November 14, 2015 [Page 1] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 [RFC2119]. 2. Introduction A full TLS handshake over TCP [RFC0793] as specified in [RFC5246] first requires establishing a TCP connection. The TCP connection establishment requires a full round (two flights) before the TCP handshake is complete and the client can send the first TLS handshake message. The TLS handshake itself requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data. Thus, using TLS can add a latency penalty of two network round-trip times for application protocols in which the client sends data first, such as HTTP [RFC2616]. An abbreviated handshake (resuming an earlier TLS session) [RFC5246] is complete after three flights, thus adding just one round-trip time if the client sends application data first. Client Server SYN --------> <-------- SYN ACK ACK ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Figure 1: Message flow for a TCP handshake followed by a full TLS 1.2 handshake Krasnov Expires November 14, 2015 [Page 2] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 Client Server SYN --------> <-------- SYN ACK ACK ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Figure 2: Message flow for a TCP handshake followed by an abbreviated TLS 1.2 handshake This document describes a technique that alleviates the latency burden imposed by TLS: the TLS Jump Start. The TLS Jump Start technique, hides the latency of the TCP protocol handshake, by sending the initial client/server messages over the UDP protocol [RFC0768] prior to the establishment of a TCP connection. Under optimal conditions the technique saves a full round worth of latency for any existing and future TLS protocols, regardless of which side sends the data first. The method does not change the data transferred over the wire, but rather the timing and delivery protocol. For an abbreviated handshake it is possible to have a TLS connection in place with almost zero latency over the simple TCP handshake. In TLS Jump Start, the first round takes place over the UDP protocol in full, while subsequent rounds, if required, continue over the TCP connection. o Under TLS 1.2 the client would send the initial ClientHello message over UDP. o Under TLS 1.2 the server would respond with ServerHello, optional Certificate, ServerKeyExchange, CertificateRequest and finally ServerHelloDone over UDP o For an abbreviated handshake the server would send the ServerHello and Finished messages over UDP Krasnov Expires November 14, 2015 [Page 3] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 3. Jump Start Compatibility TLS Jump Start, described below, is an optional feature that is backwards compatible with existing implementations. If the ClientHello message sent over UDP is lost, does not reach the server in time, or is ignored by the server, then the client will not get a response over UDP from the server and will assume the server does not support this extension. In the case where server is known or suspected to not support this option, a new ClientHello will be sent over TCP. 4. Client-side Jump Start This section specifies a change to the behavior of TLS client implementations. When the client attempts to open a Jump Start connection, it MUST first send the ClientHello message over the UDP protocol to the server. After, or simultaneously, with the ClientHello, and independently of the server response the client MUST initiate a TCP connection with the server. The ports used by the TCP and UDP SHOULD have the same number. After or during the establishment of the TCP, the client MUST check if the server responded over the UDP protocol. If the server responded, and the response is complete (i.e. no packets of the response were lost), the client MAY use the handshake data to continue the handshake over the open TCP connection, starting with the ClientKeyExchange message or the optional client Certificate message. If the response is partial the client MUST initiate a new TLS handshake by sending a new ClientHello message, with a new client random_bytes value. If there was no response the client MAY wait for a possible response via UDP for a short period of time. After that the client MUST assume the server does not support Jump Start and initiate a new TLS handshake by sending a new ClientHello message over the TCP channel. 5. Server-side Jump Start This section specifies a change to the behavior of TLS server implementations. A server supporting the Jump Start technique, MUST listen for incoming ClientHello messages over the same UDP port number it uses for TCP TLS connections. Krasnov Expires November 14, 2015 [Page 4] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 When a ClientHello reaches the server over the UDP protocol, the server MUST determine the source of the message by looking at the IP:PORT pair. If a TCP connection for the given source is open, the server MUST ignore the message. The server MUST keep a history of incoming ClientHello messages with the corresponding response messages. It MAY limit the history to a certain timeout period. If an entry exists in the history for a ClientHello for a given IP address (on any port), the server MUST ignore the new ClientHello. If the ClientHello belongs to a new connection, the server MUST respond with the appropriate response - ServerHello with the optional Certificate, ServerKeyExchange, CertificateRequest and the ServerHelloDone messages for the full handshake, or with ServerHello and Finished messages for the abbreviated handshake. The server MUST then put the handshake state in the history. When a new TCP connection is opened on the appropriate port, the server will wait for the first message from the client. If the first message is ClientHello, the server will perform a legacy handshake. The server MAY check the history for a previous ClientHello over UDP for a given source, and remove the relevant from history if it exists. If the first message is ClientKeyExchange or Certificate or Finished, the server MUST retrieve the appropriate handshake state from the history. If the retrieval failed, it indicates an error. Otherwise the server MUST continue the handshake process using the stored state, first removing the entry from history. Krasnov Expires November 14, 2015 [Page 5] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 Client Server ClientHello ========> SYN --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <======== ServerHelloDone <-------- SYN ACK ACK Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data The exact order in which the TCP and UDP information arrives is not guaranteed. Figure 3: Message flow for a full Jump Start handshake Client Server ClientHello ClientKeyExchange ========> SYN --------> ServerHello <======== {Finished} <-------- SYN ACK ACK {Finished} --------> Application Data <-------> Application Data The exact order in which the TCP and UDP information arrives is not guaranteed. Figure 4: Message flow for an abbreviated Jump Start handshake <--------> Indicates data sent over TCP <========> Indicates data sent over UDP Krasnov Expires November 14, 2015 [Page 6] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 6. Security considerations The integrity of the handshake is not affected by the delivery method. The same security considerations and guarantees applicable to TLS apply here as well. The use of a UDP protocol makes the technique vulnerable to reflection-amplification attacks similar to other UDP protocols. However due to the fact a single server will only reply once for a given IP, the amplification is very limited. Also coordinating an attack between many servers is difficult, when the network latency between the servers and the attack destination is not uniform. It is possible to further reduce the risk of such attack, by requiring the UDP ClientHello message to include a large amount of redundant data. The server will check the size of the ClientHello, and respond with a response proportionate to the original message by a certain factor. 7. IANA considerations None. 8. Implementation considerations Given the nature of the UDP protocol, it might be desirable to add some kind of an out-of-order packet processing on the client side, in case the server response is split into several UDP packets. The protocol is not designed to deal with UDP packet loss. In case of an unreliable network, it is assumed that the TCP will be a better alternative. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. Krasnov Expires November 14, 2015 [Page 7] Internet-Draft Transport Layer Security (TLS) Jump Start May 2015 9.2. Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Author's Address Vlad Krasnov CloudFlare Inc. Birchin Court, 20 Birchin Lane London EC3V 9DU UK Email: vlad@cloudflare.com Krasnov Expires November 14, 2015 [Page 8]