Internet DRAFT - draft-vkrasnov-tls-jumpstart
draft-vkrasnov-tls-jumpstart
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]
