Network Working Group E. Rescorla
Internet-Draft Mozilla
Intended status: Standards Track November 5, 2013
Expires: May 9, 2014
New Handshake Flows for TLS 1.3
draft-rescorla-tls13-new-flows-00
Abstract
This document sketches some potential new handshake flows for TLS
1.3.
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 May 9, 2014.
Copyright Notice
Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
Rescorla Expires May 9, 2014 [Page 1]
Internet-Draft TLS 1.3 Flows November 2013
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Handshake Flows . . . . . . . . . . . . . . . . . . . . . 3
2.2. Handshake Latency . . . . . . . . . . . . . . . . . . . . 4
2.3. Plaintext Data in the Handshake . . . . . . . . . . . . . 5
3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 6
4. Challenging Issues . . . . . . . . . . . . . . . . . . . . . . 7
5. New Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Reduced RTT Handshakes w/o Server-Side State . . . . . . . 8
5.1.1. Improving Privacy . . . . . . . . . . . . . . . . . . 12
5.1.1.1. A Partially Private Handshake . . . . . . . . . . 12
5.1.1.2. Partially Private Fallback . . . . . . . . . . . . 13
5.2. Reduced RTT Handshakes with Server-Side State . . . . . . 15
5.2.1. Zero Round-Trip Resumed Handshake . . . . . . . . . . 15
5.2.2. Zero Round-Trip Non-Resumed Handshake . . . . . . . . 15
5.2.3. Fallback from 0-RTT handshakes . . . . . . . . . . . . 16
5.2.4. Zero Round Trip (sort-of) with PFS . . . . . . . . . . 17
5.2.5. Anti-Replay Options . . . . . . . . . . . . . . . . . 17
5.3. Compatibility . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Some other questions to think about . . . . . . . . . . . 18
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Summary of Existing Extensions . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Rescorla Expires May 9, 2014 [Page 2]
Internet-Draft TLS 1.3 Flows November 2013
1. Introduction
DISCLAIMER: THIS IS A VERY ROUGH DRAFT. EVERYTHING HERE IS SUPER-
HANDWAVY AND HASN'T REALLY HAD ANY SECURITY ANALYSIS. I DON'T
PROMISE IT'S NOT VERY VERY WRONG BUT I WANTED TO BE ABLE TO HAVE AN
EARLY DISCUSSION ABOUT DIRECTION.
The TLS WG is specifying TLS 1.3, a revision to the TLS protocol.
The two major design goals for TLS 1.3 are:
o Reduce the number of round trips in the handshake, providing at
least "zero round-trip" mode where the client can send its first
data message immediately without waiting for any response from the
server.
o Encrypt as much of the handshake as possible in order to protect
against monitoring of the handshake contents.
This document proposes revisions to the handshake to achieve these
objectives. They are being described in a separate document and in
somewhat schematic form for ease of analysis and discussion. If they
are considered acceptable, some of them may be elaborated and
integrated into the main TLS document.
2. Background
In this section we briefly review the properties of TLS 1.2 [RFC5246]
2.1. Handshake Flows
As a reminder, this section reproduces the two major TLS handshake
variants, from [RFC5246]. For clarity, data which is
cryptographically protected by the record protocol (i.e., encrypted
and integrity protected) are shown in braces, as in {Finished}.
Rescorla Expires May 9, 2014 [Page 3]
Internet-Draft TLS 1.3 Flows November 2013
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
{Finished} -------->
[ChangeCipherSpec]
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 1: TLS 1.2 Full Handshake
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- {Finished}
[ChangeCipherSpec]
{Finished} -------->
{Application Data} <-------> {Application Data}
Figure 2: TLS 1.2 Resumed Handshake
2.2. Handshake Latency
The TLS "Full Handshake" shown above incurs 2RTT of latency: the
client waits for the server Finished prior to sending his first
application data record. The purpose of the Finished is to allow the
client to verify that the handshake has not been tampered with, for
instance that the server has not mounted a downgrade attack on the
cipher suite negotiation. However, if the client is satisfied with
the handshake results (e.g., the server has selected the strongest
parameters offered by the client), then the client can safely send
its first application data immediately after its own Finished (this
is often called either "False Start" or "Cut Through"
[I-D.bmoeller-tls-falsestart]), thus reducing the handshake latency
to 1RTT for a full handshake.
Rescorla Expires May 9, 2014 [Page 4]
Internet-Draft TLS 1.3 Flows November 2013
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
{Finished}
{Application Data} -------->
[ChangeCipherSpec]
<-------- {Finished}
{Application Data} <-------> {Application Data}
TLS 1.2 with False Start
This technique is not explicitly authorized by the TLS specification
but neither is it explicitly forbidden. A number of client
implementations (e.g., Chrome, Firefox, and IE) already do False
Start. However, because some servers fail if they receive the
Finished early, it is common to use some kind of heuristic to
determine whether a server is likely to fail and therefore whether
this optimization can be used.
The abbreviated handshake already succeeds in 1RTT from the client's
perspective.
There have been proposals to take advantage of cached state between
the client and server to reduce the handshake latency to 0RTT
[I-D.agl-tls-snapstart]. However, they have not been widely adopted.
2.3. Plaintext Data in the Handshake
As shown in the figures above, essentially the entire handshake is in
the clear. Some of these values are potentially sensitive,
including:
o The client certificate.
o The server name indication (i.e., which server the client is
trying to contact.
o The server certificate (this is only interesting when SNI is used)
Rescorla Expires May 9, 2014 [Page 5]
Internet-Draft TLS 1.3 Flows November 2013
o The next protocol in use [I-D.ietf-tls-applayerprotoneg].
o The channel ID [REF: Channel ID]
o The client cipher suite list (potentially usable for client
fingerprinting.)
There have been proposals to address this just for extensions
[I-D.agl-tls-nextprotoneg] as well as for the handshake as a whole
[I-D.ray-tls-encrypted-handshake]. In general, the amount of privacy
protection which can be provided is somewhat limited by four factors:
o A fair amount of information can be gathered from traffic analysis
based on message size and the like.
o Because the existing mechanisms do not encrypt these values, an
active attacker can generally simulate being a server which does
not accept whatever new handshake protection mechanisms are
offered and force the client back to the old, unprotected
mechanism. This form of active attack can be mitigated by
refusing to use the old mechanism, however that is not always
possible if one wishes to retain backward compatibility.
o Many inspection devices mount a man-in-the-middle attack on the
connection and therefore will be able to inspect information even
if it is encrypted.
o It's very hard to avoid attackers learning the server's
capabilities because they generally fall into an easily probe-
aoble/enumerable set and in most cases the clients are anonymous
(and thus indistinguishable from attackers). Probably the best we
can do is prevent attackers from learning which of a server's
capabilities a given client is exercising.
However, there are still advantages to providing protection against
passive inspection. The flows in this document attempt to provide
this service to the extent possible.
3. Basic Assumptions
This section lays out the basic assumptions that motivate the designs
in this document (aside from the objectives in Section 1.
Retain Basic TLS Structure: The intent of this document is to retain
the basic TLS structure and messages, tweaking them as minimally
as necessary to accomplish the objectives in Section 1.
Conservative design is good when working with security protocols.
Rescorla Expires May 9, 2014 [Page 6]
Internet-Draft TLS 1.3 Flows November 2013
Backward Compatibility is Required: It must be possible for TLS 1.3
implementations to interoperate with TLS 1.2 and below.
Minimize Variation: TLS already has a very large number of variant
handshakes which makes it confusing to analyze. We would like to
avoid multiplying this unnecessarily. We will probably deprecate
some of the old flows in TLS 1.3.
PFS is important but not mandatory: Perfect Forward Secrecy is an
important security property, but it it exists in tension with low
latency (as existing mechanisms depend on contributions from both
sides). Accordingly, we should provide PFS-compatible modes but
not mandate them.
0-RTT modes require server-side state: The existing TLS anti-replay
mechanism involves the server and client jointly contributing
nonces and therefore can be stateless on the server (as long as a
fresh nonce can be generated.) Any 0-RTT mode in which the client
sends data along with his initial handshake message must use some
other mechanism to prevent replay, and this involves the server
keeping some state.
Latency is often more important than bandwidth: Because networks are
getting faster but the speed of light is not, it is often more
important to minimize the number of round trips than the number of
bits on the wire.
Client-side computation is often cheap: In many (but not all) cases,
clients can afford to do a lot of cryptographic operations very
cheaply.
Clients can and should be optimistic: When we put together the
previous points, we come to the conclusion that it's OK for
clients to be optimistic that things will succeed. So, for
instance, it's OK to send messages to the server that might need
to be retransmitted or recomputed if the server's state is not as
expected. This is a key element of a number of round-trip
reducing strategies.
4. Challenging Issues
This section previews some known challenging issues to keep in mind
in the text below.
Rescorla Expires May 9, 2014 [Page 7]
Internet-Draft TLS 1.3 Flows November 2013
SNI privacy versus round-trips and variant server configuration: SNI
is intended to alter the behavior of the server, but it also leaks
information about the intended server identity. These demands are
in tension. In situations where the server uses incompatible
cryptography for the different SNIs (e.g., the servers use only
RSA and use different keys) it is not possible to hide the SNI.
In other cases, e.g., where DHE is used but authenticated with
different keys, it is possible to have distinct configurations but
at the cost of multiple RTs in order to first exchange keys and
then to send the encrypted SNI and then respond the server's
response.
Round-trips required for PFS: It's clearly not possible to do a
0-RTT handshake while also providing PFS. The two basic
alternatives are (1) abandon PFS for 0-RTT handshake (maybe using
re-handshakes on the same connection to get PFS) (2) Have a two-
stage crypto exchange where the client initially uses a key
generated using a cached server DH share and then and then later
uses a key generated from a fresh server DH share.
5. New Flows
This document includes a number of strategies for improving latency
and privacy, including:
o Move the CCS up in the handshake with respect to other messages so
that more of the handshake can be encrypted, thus improving
protection against passive handshake inspection.
o Allow the client to send at least some of his second flight of
messages (ClientKeyExchange, Finished, CCS, etc.) together with
the first flight in the full handshake, thus improving latency.
o Allow the client to send data prior to receiving the server's
messages, thus improving latency.
In addition, where prior versions of TLS generally assume that the
client is totally ignorant of the server's capabilities (e.g.,
certificate and supported cipher suites) we assume that the client
either knows them or can make a good guess (see [REF: Fast Track])
for an early example of this.)
5.1. Reduced RTT Handshakes w/o Server-Side State
NOTE: THIS SECTION IS PEDAGOGICAL. The flows in this section are
not flows we probably want to adopt, but they provide a somewhat
easier introduction into what we are trying to do.
The basic idea behind doing a 1RTT handshake is that the client has
Rescorla Expires May 9, 2014 [Page 8]
Internet-Draft TLS 1.3 Flows November 2013
some information about the server's likely parameters. Specifically,
it believes it knows:
o The server's preferred cipher suite.
o The server's certificate and persistent ServerKeyExchange
parameters.
For starters, let's look at what we can accomplish if we don't care
about improving privacy.
The handshake below, modelled on Fast Track and some suggestions from
Brian Smith, exploits this fact to reduce handshake latency.
Client Server
ClientHello + CI
ClientKeyExchange -------->
ServerHello + CI
Certificate*
ServerKeyExchange*
ServerHelloDone
[ChangeCipherSpec]
<-------- {Finished}
[ChangeCipherSpec]
{Finished}
{Application Data} -------->
{Application Data} <-------> {Application Data}
Figure 3: Full handshake (fast track-ish) [PEDAGOGICAL]
In this diagram, "CI" refers to the cached info extension
[I-D.ietf-tls-cached-info] which allows the client and the server to
jointly agree that the client knows the servers parameters. Note
that currently cached info includes the server's certificate but not
the server's DH or ECDH parameters (Fast-Track included both) and
would need to be modified to support this usage. However, the
modification is straightforward. [[IMPORTANT PRESENTATION NOTE: We
are showing the ClientKeyExchange as a separate message, but
obviously this is bad news for a pre-TLS 1.3 server (see Section 5.3
on compatibility, We really need to stuff any extra messages sent
with the ClientHello in an extension as done in
[I-D.agl-tls-snapstart], but that makes the diagrams too clumsy.
Please imagine that change where appropriate below.]]
This handshake allows the client and the server to establish keys in
1RTT (from the client's perspective) and the server to start
Rescorla Expires May 9, 2014 [Page 9]
Internet-Draft TLS 1.3 Flows November 2013
transmitting upon receiving the client's first message. Note that
the client need not have encountered the server before, especially
with ECDHE. If many servers support a common parameter set the
client can just send a key valid for that parameter set, at the cost
of some additional, potentially unnecessary, computation.
Obviously, there is some risk that the client is incorrect about the
server's keying material, either because it has made a mistake or the
server has changed it. In this case, the server responds with a
ServerHello w/o the CI extension and the client is forced back to the
usual TLS 1.2-style handshake, as below.
Client Server
ClientHello + CI
ClientKeyExchange -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
{Finished} -------->
[ChangeCipherSpec]
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 4: Fallback to full handshake [PEDAGOGICAL]
This design has two major drawbacks:
o It's not possible to do client authentication strictly in 1RT
(which is why the client authentication modes are not shown in
Figure 3).
o We still haven't done anything to encrypt much of the handshake.
The ultimate reason for both of these problems is replay protection
for the server. Specifically, we need the ServerHello containing the
server's Random value before we can generate the keying material
needed to encrypt the handshake messages. Similarly, because the
CertificateVerify incorporates a random challenge provided by the
server, it can't be generated before the CertificateRequest has been
provided, which adds a second round-trip.
Let's look at the client authentication problem first. One
Rescorla Expires May 9, 2014 [Page 10]
Internet-Draft TLS 1.3 Flows November 2013
possibility would be to just leave the handshake as shown above and
just add the CertificateRequest in the server's first flight and the
Certificate/CertificateVerify in the client's second flight.
Unfortunately, this changes the semantics of Finished so that the
server's Finished message no longer covers the entire handshake.
It's not clear what security issues this introduces, but it seems
undesirable.
A better approach seems to be to introduce another server message
that just confirms the first phase of the handshake. This can have
the same calculation as the Finished message, but would appear
(unencrypted) in the server's first flight, as shown below:
Client Server
ClientHello + CI
ClientKeyExchange -------->
ServerHello + CI
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------- AlmostFinished
Certificate*
CertificateVerify*
[ChangeCipherSpec]
{Finished}
{Application Data} -------->
[ChangeCipherSpec]
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 5: Full handshake (fast track-ish with client auth)
[PEDAGOGICAL]
Note: this handshake is not compatible with key exchange mechanisms
which require a static client-side key. However, these are not
widely used in any case. It is compatible with PFS cipher suites as
long as the server uses stable parameters, because the client sends
his share prior to seeing the ServerKeyExchange.
[[OPEN ISSUE: Should we move the server's CCS up to before the
AlmostFinished? Doesn't seem to add much value.]] [[OPEN ISSUE:
Need a better name for AlmostFinished.]]
Rescorla Expires May 9, 2014 [Page 11]
Internet-Draft TLS 1.3 Flows November 2013
5.1.1. Improving Privacy
We still have not done anything to improve the privacy of the
handshake, however, it is possible to improve it a fair bit by
splitting the ServerHello and moving the ServerKeyExchange and CCS
messages (and hence the encryption boundary) upward in a fashion
similar to that suggested by Ray [I-D.ray-tls-encrypted-handshake].
5.1.1.1. A Partially Private Handshake
Client Server
ClientHello + CI
ClientKeyExchange -------->
ServerHello[1] + CI
ServerKeyExchange*
[ChangeCipherSpec]
{ServerHello[2]}
{Certificate*}
{CertificateRequest*}
{ServerHelloDone}
<-------- {AlmostFinished}
[ChangeCipherSpec]
{Certificate*}
{CertificateVerify*}
{Finished}
{Application Data} -------->
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 6: 1RTT handshake with partial privacy
Note that this handshake contains two ServerHellos, which I have
labelled ServerHello[1] and ServerHello[2]. The first ServerHello
contains just the minimal information to indicate that the client's
proposed parameters are acceptable (mostly what Fast Track calls the
"determining parameters") with most of the information (i.e., the
server's cert, most extensions, etc.) being in the second
ServerHello. Thus, nearly all the information which we consider
sensitive is encrypted, with the exception of information which
appears in the client hello, which obviously cannot be protected (see
below). As an example, if ALPN is in use, the clients offered list
of next protocols is visible but the server's selection is not.
[[OPEN ISSUE: Should these ServerHellos have different names/code
points as in [I-D.ray-tls-encrypted-handshake] There is some
redundant data in the second ServerHello (e.g., the random values),
Rescorla Expires May 9, 2014 [Page 12]
Internet-Draft TLS 1.3 Flows November 2013
so that's annoying, but it might be nice to have the same messages so
that we can have it appear in a bunch of different places without
inventing new message names. This is a second-order issue.]]
Notably, both certificates are encrypted, but the SNI is in the
clear, so a passive attacker can infer the server's identity. This
is not ideal (see below) but is a compromise to remove round trips.
In addition, because the ServerKeyExchange includes a signature over
the keys, an attacker can verify whether a given known certificate
was used.
5.1.1.2. Partially Private Fallback
If the client is incorrect about the server's parameters (e.g., he
guesses the wrong DH parameters) then the client gets forced into a
slow-path handshake, as shown in Figure 7.
Client Server
ClientHello[1] + CI
ClientKeyExchange -------->
ServerHello[1]
<-------- ServerKeyExchange*
ClientHello[2] + CI
ClientKeyExchange
[ChangeCipherSpec]
{ClientHello[3]} -------->
[ChangeCipherSpec]
{ServerHello}
{Certificate*}
{ServerKeySignature*}
{CertificateRequest*}
{ServerHelloDone}
<-------- {AlmostFinished}
{Certificate*}
{CertificateVerify*}
{Finished}
{Application Data} -------->
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 7: Falling back from 1RTT handshake with partial privacy
This should be familiar from Figure 4: the client sends a
ClientHello but incorrectly predicts the server's parameters; the
server responds with a correction indicating the parameters he wants
to negotiate. This also includes a ServerKeyExchange to carry the
Rescorla Expires May 9, 2014 [Page 13]
Internet-Draft TLS 1.3 Flows November 2013
server's DHE/ECDHE public key (i.e., not just the parameters). Note
that the SKE must be unsigned because otherwise that reveals the
server's certificate. At this point, the client adopts the new
information about the server's state and sends a ClientHello[2] which
hopefully has a more accurate prediction. [[OPEN ISSUE: Should we
let this cycle repeat again if the client is still somehow wrong?
Probably generate an alert.]]
As before, the client can now send a ClientKeyExchange, but because
the client now has the server's public keying material, at this point
it has established a joint key which it can use for encryption. It
can therefore send a ClientHello[3] with the extensions information
it considers sensitive (see Appendix A.) [[OPEN ISSUE: Again, we
should consider giving these different names, though here
ClientHello[1] and ClientHello[2] probably should both be
ClientHellos and ClientHello[3] is mostly extensions.]]
The server responds with his true second flight which is mostly
encrypted but otherwise mostly as normal. The major change here is
that it now includes a ServerKeySignature which covers the
ServerKeyExchange from the first flight.
Note that we've actually killed two birds with one stone here.
First, we've dealt with the case where the client is incorrect about
the server's capabilities, providing ourself with a fallback
mechanism. Second, we've provided privacy for nearly the entire
handshake. Thus, a client which wishes to conceal the extensions in
his handshake just sends a ClientHello with a non-matching CI
extension, thus eliciting the server's key, and can then use that to
encrypt the rest of the handshake.
There is one important limitation to mention regarding the use of SNI
here. The handshake described in this section only works if all of
the SNI values served by the server can use the same public key,
either because they have the same RSA public key for all of their
certificates and static RSA is used (not clear how likely this is) or
because they all share the same DH/ECDH parameters (this seems
reasonably likely). In cases where different SNI values require
different determining parameters, then it is not possible to protect
SNI and the server must somehow indicate that the client should
simply retry with an ordinary handshake with SNI. There are probably
a number of ways to indicate this, but (for instance) we could invent
a new extension value or nonfatal alert (recall that this is only
needed once the client has indicated TLS 1.3 so there is no
compatibility issue.)
Rescorla Expires May 9, 2014 [Page 14]
Internet-Draft TLS 1.3 Flows November 2013
5.2. Reduced RTT Handshakes with Server-Side State
Without server-side state, the best-case scenario is one round trip.
If we are willing to assume that the server has state, we can shorten
this to zero round trips (though at the cost of PFS). The general
principle is that each client handshake contains a unique value
(e.g., the ClientRandom) and the server memorizes a list of which
handshakes have occurred and thus can detect replay by simply
checking to see if a given handshake is a replay or not. This idea
appears in (for instance) [I-D.agl-tls-snapstart]. See Section 5.2.5
for some options here.
If everything goes well (the server has not changed its
configuration, rebooted and lost its state, etc.) the client can
follow its initial message flight (ClientHello, etc.) with encrypted
data which the server will process. However, as with the handshakes
in Section 5.1, there is some possibility that the server will reject
the client's parameters, in which case the client will need to fall
back to the slow-path.
5.2.1. Zero Round-Trip Resumed Handshake
The resumed fast-path flow is shown below.
Client Server
ClientHello + CI + AR
[ChangeCipherSpec]
{Finished}
{Application Data} -------->
ServerHello + CI + AR
[ChangeCipherSpec]
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 8: Zero Round-trip resumed handshake
The new "AR" field indicates an anti-replay indicator. See
Section 5.2.5 for details.
5.2.2. Zero Round-Trip Non-Resumed Handshake
In the handshake shown in Figure 8, because the client's SessionID
(or SessionTicket) is carried in the clear, it is possible to link
multiple handshakes initiated by the same client. This obviously
isn't an ideal property and can be addressed by not doing resumption
and instead doing a 0-RTT key exchange.
Rescorla Expires May 9, 2014 [Page 15]
Internet-Draft TLS 1.3 Flows November 2013
The idea here is that the server's public key (i.e., not just the DH/
ECDH parameters) is reasonably static (either it's an RSA key or a
reasonably stable DHE key). The client can then send a
ClientKeyExchange message which, combined with the stateful anti-
replay information, is enough to set up the entire connection, as
shown in Figure 9.
Client Server
ClientHello[1] + CI + AR
ClientKeyExchange
{ClientHello[2]}
[ChangeCipherSpec]
{Certificate*}
{CertificateVerify*}
{Finished}
{Application Data} -------->
ServerHello[1]
[ChangeCipherSpec]
{ServerHello[2]}
{ServerHelloDone}
<-------- {Finished}
{Application Data} <-------> {Application Data}
Figure 9: Zero Round-Trip non-resumed handshake
NOTE 1: This (potentially) includes the client's Certificate and
CertificateVerify because the client still needs to prove himself to
the server, but the server doesn't need to prove himself to the
client since the client has memorized the server's information.
NOTE 2: As usual, we need the client's Finished message to cover the
server's expected messages. We will need to use some Snap Start-
style trick to have the client include that. I believe we can solve
this by shoving it in the CI, but the details need to be worked out.
If the client's predictions of the server data are incorrect, then
you fall back as in previous sections.
5.2.3. Fallback from 0-RTT handshakes
In either of the handshakes shown in the two preceding sections,
there is a risk that the client will be wrong about the server's
parameters. The question then becomes how aggressive we want to be
about fallback. One attitude would be to say that we want minimum
protocol complexity and that therefore we want to fall back to the
slowest possible path, namely the 2-RTT handshake im Figure 7.
Rescorla Expires May 9, 2014 [Page 16]
Internet-Draft TLS 1.3 Flows November 2013
The other attitude is to say that we want things to be as fast as
possible, in which case we might want to fall back from the resumed
0-RTT handshake in Figure 8 to the non-resumed 0-RTT handshake in
Figure 9 to the 1-RTT handshake in Figure 6 or to Figure 9, and then
only to the 2-RTT handshake in Figure 7. This should be technically
possible, at the cost of the client having to optimistically include
a pile of extra stuff and having some way to phrase "use this data in
this condition" in the protocol. On the other hand, it's also
obviously pretty complicated.
5.2.4. Zero Round Trip (sort-of) with PFS
Obviously, the handshake shown in Figure 9 does not provide PFS.
This can be partly worked around by having the server use short-lived
DH keys, but at the cost of increasing the number of times you fall
back to a slower handshake (because the client is wrong about the
key.) Obviously if the client wants total PFS, he can just initiate
one of the 1RTT handshakes, but there are two main options for
getting PFS for some of the data but not all:
o Do a complete rehandshake with a full DH exchange immediately
after the resumed handshake. This gives you PFS coverage for some
of the data but at some not-entirely-deterministic time.
o Have the client do two key exchanges, one with the semi-stable
server key and one with a new key supplied by the server in his
response. So, in Figure 9 we would add a ServerKeyExchange. The
server's application data would be encrypted with the new PFS key
and the client's application data after receiving the server's
response would be as well. However, the client's initial data
would be encrypted with a non-PFS key. [[OPEN ISSUE: how does
the server determine what is what? Trial decryption? Client
sentinel message?]]
5.2.5. Anti-Replay Options
There are a number of potential mechanisms for detecting replay on
the server side. This section lists the main ones I know of:
o Memorize arbitrary client values, typically within some scope, (as
in [I-D.agl-tls-snapstart])
o Force the client to use an identifier + values in some ordered way
(e.g., by using a sliding anti-replay bitmask)
o Give the client some finite number of tokens that you remember
until they are used (as an enhancement, these could be DH public
keys)
Each of these approaches has costs and benefits; generally the exact
form of the anti-replay mechanism is orthogonal to the design of
Rescorla Expires May 9, 2014 [Page 17]
Internet-Draft TLS 1.3 Flows November 2013
0-RTT handshake.
5.3. Compatibility
The high-order compatibility issue for any change to TLS is whether
the ClientHello is compatible with old servers. To a first order, we
deal with this by putting any new information in extensions. This is
ugly, but mostly works.
However, a secondary problem becomes that some servers/accelerators
are unhappy with large ClientHello messages (see
https://www.imperialviolet.org/2013/10/07/f5update.html). As we
optimistically put more stuff in the ClientHello, including keys and
even data, we are likely to start running into problems here.
Generally, we can avoid putting data into the ClientHello unless the
server has indicated somehow that it is able to accept it, which
should help minimize problems except if people's configurations
change or they have truly broken/mixed configurations. Nevertheless,
we need to take care here or else decide we are willing to deal with
some level of incompatibility.
5.4. Some other questions to think about
[TODO]
o Should we get rid of resumption?
o Should we get rid of renegotiation?
o Standardized DH parameters?
o Should we get rid of static RSA entirely?
6. Backward Compatibility
[TODO]
7. Security Considerations
Everything in this document needs further analysis to determine if it
is OK.
8. Acknowledgements
This document borrows ideas from a large number of people, including
Dan Boneh, Wan-Teh Chang, Cullen Jennings, Adam Langley, Nagendra
Modadugu, Bodo Moeller, Marsh Ray, Hovav Shacham, Martin Thomson, and
Brian Smith.
Rescorla Expires May 9, 2014 [Page 18]
Internet-Draft TLS 1.3 Flows November 2013
9. References
9.1. Normative References
[I-D.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension",
draft-ietf-tls-cached-info-15 (work in progress),
October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
9.2. Informative References
[I-D.agl-tls-nextprotoneg]
Langley, A., "Transport Layer Security (TLS) Next Protocol
Negotiation Extension", draft-agl-tls-nextprotoneg-04
(work in progress), May 2012.
[I-D.agl-tls-snapstart]
Langley, A., "Transport Layer Security (TLS) Snap Start",
draft-agl-tls-snapstart-00 (work in progress), June 2010.
[I-D.bmoeller-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start",
draft-bmoeller-tls-falsestart-00 (work in progress),
June 2010.
[I-D.ietf-tls-applayerprotoneg]
Friedl, S., Popov, A., Langley, A., and S. Emile,
"Transport Layer Security (TLS) Application Layer Protocol
Negotiation Extension", draft-ietf-tls-applayerprotoneg-03
(work in progress), October 2013.
[I-D.ray-tls-encrypted-handshake]
Ray, M., "Transport Layer Security (TLS) Encrypted
Handshake Extension", draft-ray-tls-encrypted-handshake-00
(work in progress), May 2012.
Appendix A. Summary of Existing Extensions
Many of the flows in this document have Extensions appear both both
Rescorla Expires May 9, 2014 [Page 19]
Internet-Draft TLS 1.3 Flows November 2013
in the clear and encrypted. This section attempts to provide a
first-cut proposal (in table form) of which should appear where.
Extension Privacy level Proposed Location
--------------------------------------------------------------
server_name Medium Server chooses (*)
max_fragment_length Low Clear
client_certificate_url High Encrypted
trusted_ca_keys Low Server chooses (*)
truncated_hmac Low Clear
status_request Low Encrypted
user_mapping ? ?
client_authz ? ?
server_authz ? ?
cert_type Low Server chooses (*)
elliptic_curves Low Clear
ec_point_formats Low Clear
srp High ????
signature_algorithms Low Clear
use_srtp Low Encrypted
heartbeat Low Encrypted
alpn Medium Encrypted
status_request_v2 Low Encrypted
signed_certificate_timetamp ? ?
SessionTicket TLS Medium Encrypted/Clear ***
renegotiation_info Low Encrypted
* The server may need these in the clear but the client
would prefer them encrypted.
*** The SessionTicket must appear in the clear when resuming but
can be encrypted when being set up.
The general principle here is that things should be encrypted where
possible; extensions generally are proposed to be in the Clear part
of handshake only if it seems they must be there to make the rest of
the handshake work. The things that seem problematic are those which
leak information about the client's dynamic state (as opposed to
implementation fingerprinting) but are potentially needed by the
server for ciphersuite selection. These are labelled "Server
Chooses" in this table.
It's possible we can make life somewhat simpler by deprecating some
unused extensions, but based on the table above, it looks like the
extensions that make life complicated are not the ones that can be
easily removed.
Rescorla Expires May 9, 2014 [Page 20]
Internet-Draft TLS 1.3 Flows November 2013
Author's Address
Eric Rescorla
Mozilla
2064 Edgewood Drive
Palo Alto, CA 94303
USA
Phone: +1 650 678 2350
Email: ekr@rtfm.com
Rescorla Expires May 9, 2014 [Page 21]