Internet DRAFT - draft-rescorla-tls13-new-flows
draft-rescorla-tls13-new-flows
Network Working Group E. Rescorla
Internet-Draft Mozilla
Intended status: Standards Track February 17, 2014
Expires: August 21, 2014
New Handshake Flows for TLS 1.3
draft-rescorla-tls13-new-flows-01
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 August 21, 2014.
Copyright Notice
Copyright (c) 2014 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 August 21, 2014 [Page 1]
Internet-Draft TLS 1.3 Flows February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Handshake Flows . . . . . . . . . . . . . . . . . . . . . 4
2.2. Handshake Latency . . . . . . . . . . . . . . . . . . . . 5
2.3. Plaintext Data in the Handshake . . . . . . . . . . . . . 6
3. Basic Assumptions . . . . . . . . . . . . . . . . . . . . . . 7
4. Challenging Issues . . . . . . . . . . . . . . . . . . . . . . 8
5. Design Principles . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Backward Compatibility is Required . . . . . . . . . . . . 9
5.2. Remove Static Key Exchange . . . . . . . . . . . . . . . . 9
5.3. Protect SNI But Require Common Crypto Parameters . . . . . 10
6. New Handshake Modes . . . . . . . . . . . . . . . . . . . . . 10
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. New Behaviors . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Client Behavior for First Flight . . . . . . . . . . . 12
6.2.1.1. No Knowledge . . . . . . . . . . . . . . . . . . . 12
6.2.1.2. Server Keying Material . . . . . . . . . . . . . . 13
6.2.1.3. Anti-Replay Token . . . . . . . . . . . . . . . . 13
6.2.2. Server Behavior For First Flight . . . . . . . . . . . 14
6.2.2.1. Non-Optimistic Handshakes . . . . . . . . . . . . 15
6.2.2.2. Predicted Parameters Correct . . . . . . . . . . . 15
6.2.3. Client Processing of First Flight . . . . . . . . . . 17
6.2.3.1. Successful first Flight But No Anti-Replay . . . . 17
6.2.3.2. Complete 0-RTT Handshake . . . . . . . . . . . . . 18
6.2.4. Session Resumption . . . . . . . . . . . . . . . . . . 18
6.3. Example Flows . . . . . . . . . . . . . . . . . . . . . . 18
6.4. New/Modified Messages . . . . . . . . . . . . . . . . . . 20
6.4.1. EarlyData Extension . . . . . . . . . . . . . . . . . 20
6.4.2. EncryptedExtensions . . . . . . . . . . . . . . . . . 21
6.4.3. PredictedParameters . . . . . . . . . . . . . . . . . 21
6.4.4. ServerKeyExchange . . . . . . . . . . . . . . . . . . 22
6.4.5. ServerParameters . . . . . . . . . . . . . . . . . . . 23
6.4.6. Anti-Replay Token . . . . . . . . . . . . . . . . . . 23
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
Rescorla Expires August 21, 2014 [Page 2]
Internet-Draft TLS 1.3 Flows February 2014
8.1. Limits Of Identity Hiding . . . . . . . . . . . . . . . . 25
8.2. Partial PFS . . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 27
A.1. EarlyData Extension . . . . . . . . . . . . . . . . . . . 27
A.2. Always Encrypt Client Parameters . . . . . . . . . . . . . 27
A.3. Always Restarting Non-Optimistic Handshakes . . . . . . . 28
A.4. Still TODO... . . . . . . . . . . . . . . . . . . . . . . 28
Appendix B. Summary of Existing Extensions . . . . . . . . . . . 28
Appendix C. Non-recommended Flows . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Rescorla Expires August 21, 2014 [Page 3]
Internet-Draft TLS 1.3 Flows February 2014
1. Introduction
DISCLAIMER: THIS IS A ROUGH DRAFT. EVERYTHING HERE IS SOMEWHAT
HANDWAVY AND HASN'T REALLY HAD ANY SECURITY ANALYSIS.
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 for
ease of analysis and discussion. If they are considered acceptable,
some of them may be 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 August 21, 2014 [Page 4]
Internet-Draft TLS 1.3 Flows February 2014
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 August 21, 2014 [Page 5]
Internet-Draft TLS 1.3 Flows February 2014
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
application data 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 the server
supports name-based virtual hosting via SNI)
Rescorla Expires August 21, 2014 [Page 6]
Internet-Draft TLS 1.3 Flows February 2014
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 probable/
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 August 21, 2014 [Page 7]
Internet-Draft TLS 1.3 Flows February 2014
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.
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.
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
Rescorla Expires August 21, 2014 [Page 8]
Internet-Draft TLS 1.3 Flows February 2014
then to send the encrypted SNI and then respond to 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. The latter
approach seems too expensive to do on a regular basis.
5. Design Principles
5.1. Backward Compatibility is Required
It must be possible for TLS 1.3 implementations to interoperate with
TLS 1.2 and below. In the vast majority of cases this has to happen
cleanly and without a whole pile of extra round trips. This means
that, for instance, you can't just unconditionally send a ClientHello
that no TLS 1.2 server can accept and then do application layer
fallback. It may be acceptable to do so with a server you have good
reason to believe knows TLS 1.3, but that must not happen frequently
and there must be a fast way to fall back that never (or almost
never) fails.
5.2. Remove Static Key Exchange
We propose to eliminate all the static key exchange modes; this
principally means RSA since that is widely used (whereas static DH
and ECDH is not). The two major arguments for this change are:
o Static cipher suites are inherently non-forward secure. Modern
practice favors forward-secure algorithms.
o They add protocol complexity because we need to handle both
ephemeral and static modes.
In addition, RSA has a much worse performance/nominal security
profile than the ECDHE modes which we are likely to use for ephemeral
keying.
The major argument for continuing to allow static RSA is performance,
but ECDHE is fast enough that RSA + ECDHE is only marginally slower
than static RSA. Note that ephemeral keying can be used with the
existing RSA certificates, so there is no new deployment cost for
servers.
Rescorla Expires August 21, 2014 [Page 9]
Internet-Draft TLS 1.3 Flows February 2014
5.3. Protect SNI But Require Common Crypto Parameters
If you want to encrypt SNI data, then the server needs to be willing
to do encryption with the same keying material for all the virtual
servers; since we have banned static RSA above, that means
effectively the same DHE/ECDHE group. Also, encrypted SNI is
inherently incompatible with TLS 1.2 and below, since those servers
need to be able to see the SNI in order to know what certificate to
choose. Thus, any use of encrypted SNI will either need to come with
some sort of at least semi-graceful fallback to non-encrypted SNI or
accept that encrypted SNI can only be used with known TLS 1.3
servers. This does not mean, however, that the server cannot use a
different certificate; it merely needs to be willing to advertise and
use the same initial ephemeral key for each virtual server.
6. New Handshake Modes
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, CCS, Finished, 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
has prior information about the server, either from prior contact or
some discovery mechanism such as DNS.
6.1. Overview
Our basic target is a 1-RTT handshake predicated on the assumption
that the client has a semi-static DHE/ECDHE key for the server. This
key can have been acquired in a number of possible ways, including a
prior interaction, a DNS lookup, or via an extra round trip in the
same handshake. Assuming that the client knows this key, you end up
with the handshake shown in Figure 3.
Rescorla Expires August 21, 2014 [Page 10]
Internet-Draft TLS 1.3 Flows February 2014
Client Server
ClientHello
+ PredictedParameters
ClientKeyExchange
[ChangeCipherSpec]
{EncryptedExtensions} --------->
ServerHello
ServerKeyExchange
[ChangeCipherSpec]
{EncryptedExtensions}
{Certificate*}
{CertificateRequest*}
{ServerParameters*}
{CertificateVerify*}
<--------- {Finished}
{[ChangeCipherSpec]}
{Certificate*}
{CertificateVerify*}
{Finished} --------->
<--------- {Finished ???}
Figure 3: Basic 1-RTT Handshake
The most important thing to note about this handshake is that because
the client has initial knowledge of the server's key, the client
sends data to the server using two different cryptographic contexts.
The first is established by pairing the server's previously-known key
pair with the client's key and is used only to encrypt the client's
in the first flight. These messsages do not get PFS. The second
context is based on the server's ephemeral key found in the
ServerKeyExchange and the client's ephemeral key share and is used to
encrypt the rest of the handshake messages and any subsequent data.
These messages can have PFS. Note that the client sends two
ChangeCipherSpec messages in order to delineate the transition
between cleartext and the first context and then between the first
and second contexts.
This basic handshake can be extended with two major variants:
o If the client has no knowledge of the server's parameters, it
sends an initial ClientHello to solicit the server's DHE/ECDHE
key. Once it has the server's key, it simply sends the same
handshake messages as shown above. This is shown in Figure 4
o Once the client and server have communicated once, they can
establish an anti-replay token which can be used by the client to
do a 0-RTT handshake with the server in future. This is shown in
Figure 5.
Rescorla Expires August 21, 2014 [Page 11]
Internet-Draft TLS 1.3 Flows February 2014
[[OPEN ISSUE: This document does not currently discuss
renegotiation. It is an open question whether we should do so.]]
6.2. New Behaviors
6.2.1. Client Behavior for First Flight
The contents of the client's initial flight (what would be the
ClientHello in TLS 1.2 and below) depend on the client's knowledge --
or at least beliefs -- about the server. The remainder of this
section describes appropriate client behavior in each of the major
cases. Note that these cases are described in sequence of increasing
client knowledge. The client may of course be wrong about the
server's state.
6.2.1.1. No Knowledge
In the simplest case, the client has no knowledge of the server's
state and does not wish to do anything speculative. In that case,
the client simply generates a standard TLS ClientHello with
essentially the same contents as would be in TLS 1.2 (though with a
TLS 1.3 version number). This ClientHello is backward compatible
with existing TLS 1.2 servers, modulo any issues with version
negotiation.
The client has two options here vis-a-vis sensitive information in
the extensions (principally SNI and/or ALPN).
o Send a message without SNI and ALPN. This will be compatible with
any TLS 1.3 server because that server will respond with its DHE
key, but may have compatibility issues with TLS 1.2 servers which
have differential behavior for SNI and ALPN.
o Send a message with SNI and/or ALPN. This will be compatible with
TLS 1.2 servers as well as TLS 1.3 but leaks some potentially
sensitive information.
If the client has strong reason to believe that the server supports
TLS 1.3, it SHOULD use the first option. [[OPEN ISSUE: Is there a
way to have clean fallback if the client doesn't provide SNI? Need
to determine how TLS 1.2 and below servers behave if you (a) offer a
high version of TLS and (b) don't offer SNI. I suspect they offer a
default certificate in which case you could detect this case. This
is not an issue for ALPN, since you just won't negotiate the next
protocol.]]
In either case, a TLS 1.3 server will respond to this message with a
ServerKeyExchange, as in Section 6.2.2.1. The client then knows the
server's keying material and so can restart the handshake as
Rescorla Expires August 21, 2014 [Page 12]
Internet-Draft TLS 1.3 Flows February 2014
described in the next section.
6.2.1.2. Server Keying Material
Once the client knows a valid DHE/ECDHE share for the server, it can
start to send encrypted handshake data (but not application data)
immediately. In order to do so, it SHOULD send along with its
ClientHello:
o A PredictedParameters (Section 6.4.3) message containing the
expected server selected parameters based on previous negotiations
or other out of band information. Note that the client is not
selecting out of server preferences; it is attempting to predict
the cipher suites the server will select out of the client's
advertised preferences.
o A ClientKeyExchange message containing an appropriate DHE/ECDHE
share.
o A ChangeCipherSpec message to indicate that it is now sending
encrypted data.
o An EncryptedExtensions (Section 6.4.2) message containing any
extensions which should be transmitted confidentially such as SNI
or ALPN.
In order to preserve compatibility with pre TLS 1.3 intermediaries
all of this data is packed into an EarlyData extension
(Section 6.4.1).
The encryption keys for the encrypted messages are computed using the
ordinary PRF construction but with an all-zero ServerRandom value.
Thus implies that there is no guarantee of freshness from the
server's side but that the client knows that the keying material is
fresh provided it generated the ClientRandom correctly. [[OPEN
ISSUE: If the client and server have previously exchanged messages
(see Section 6.2.1.1) then we could use that ServerRandom, but this
just makes the security properties more confusing.]]
6.2.1.3. Anti-Replay Token
If the client also has an anti-replay token (see Section 6.4.6 for
details) it can act as in the previous section but also include the
anti-replay information in the EncryptedExtensions message (the
information is encrypted here to avoid linkage between multiple
handshakes by the same client).
If previous interactions with the same server indicate that client
authentication is required [[TODO: provide an explicit signal for
this in either ServerParameters or CertificateRequest]], the client
MUST also provide Certificate and CertificateVerify messages.
Rescorla Expires August 21, 2014 [Page 13]
Internet-Draft TLS 1.3 Flows February 2014
In addition, a client MAY include one or more encrypted
application_data records containing data for the server to process.
These records MUST follow the Finished message.
[[TODO: We need to tie the CertificateVerify to the server
certificate. In the other handshakes, this binding is a side effect
of having the server certificate supplied in the handshake. Here,
the certificate is implicit, so the client's signature doesn't cover
it automatically. One option is to have the client replay the
server's Certificate message after the AntiReplayToken. The
cached_information extension could allow this to be replaced with a
hash of the same.]]
6.2.2. Server Behavior For First Flight
Upon receiving the client's first flight, the server must examine
both the ClientHello information and the EarlyData information to
determine the extent to which the client has optimistically added
information and the extent to which the client's optimism is
warranted. The server SHOULD follow the following algorithm or an
equivalent one:
1. If the client's maximum version number is less than 1.3, then
proceed as defined in [RFC5246].
2. Perform cipher suite negotiation and extension negotiation as
specified in [RFC5246] and remember the results and the resultant
ServerHello. NOTE: This is why SNI requires the cryptographic
parameters to be identical for each virtual host.
3. If the client has not included a ClientKeyExchange in the
ClientHello, this is a non-optimistic handshake, proceed as
described Section 6.2.2.1. Send a ServerHello and
ServerKeyExchange to give the client the server's parameters.
4. If the ClientKeyExchange message is incompatible with the
negotiated parameters, then this is a failed optimistic handshake
Proceed as in Section 6.2.2.1.
5. If a PredictedParameters message is present, check that it
matches the negotiated parameters from step 2. Note that this
means that the client must predict *exactly* the cipher suite and
compression parameters that the server selects. If there is a
failed match, this is a failed optimistic handshake so proceed as
if it were not optimistic (See Section 6.2.2.1.) Otherwise, this
is a successful optimistic handshake, so proceed as in
Section 6.2.2.2.
6. Anything else is an error.
[[TODO: rewrite the logic here for more clarity??]]
Rescorla Expires August 21, 2014 [Page 14]
Internet-Draft TLS 1.3 Flows February 2014
6.2.2.1. Non-Optimistic Handshakes
In the case where the client has not been optimistic or has been
optimistic but wrong, the server simply sets the client's
expectations so that the client can try again. Specifically, this
means that the server responds with the following messages:
o ServerHello indicating the negotiated parameters.
o ServerKeyExchange (Section 6.4.4)
o ServerHelloDone
[[OPEN ISSUE: This looks a lot like the of the messages described in
Section 6.2.2.2, so the client needs to infer that he needs to
restart based on the ServerHelloDone being present and Finished being
absent. This works, but it might be better to make it more explicit
by adding a new message such as HelloRequest.]]
The server MUST ignore any client extensions which are not necessary
to negotiate the cryptographic parameters. This does not mean that
they will not be used, merely that they will be negotiated in a
subsequent exchange. Note that TLS 1.2-compatible clients generally
will need to put SNI and perhaps ALPN in their ClientHello. Because
TLS 1.3 servers MUST use common cryptographic parameters regardless
of these extensions (see Section 5.3), the server MUST ignore these
values. The client responds to these messages by sending a new
Clienthello that conforms to the servers known expectations, as in
Section 6.2.1.2. The original round-trip messages MUST be included
in the handshake hashes for the Finished to tie them to the rest of
the handshake.
[[OPEN ISSUE: This is a deliberately missed opportunity for a modest
optimization. If the client has already provided a full ClientHello
as would be needed for TLS 1.2, then the server could do a TLS 1.2-
style handshake including sending its Certificate,
CertificateRequest, etc., whereas we now have to have a full round
trip. However, in the name of reducing protocol complexity, we are
eschewing this. An alternate choice would be to simply fall back to
the TLS 1.2 behavior and do a TLS 1.2-style handshake.]]
6.2.2.2. Predicted Parameters Correct
If the client has correctly predicted the server parameters (i.e.,
the cipher suite, compression, etc. that the server would have
selected based on the ClientHello), then the client and server now
share a PreMaster Secret based on the client's ClientKeyExchange and
the previously provided ServerParameters. The server computes the
PMS, Master Secret, and traffic keys and decrypts the rest of the
client's handshake messages. If any non-handshake messages are
Rescorla Expires August 21, 2014 [Page 15]
Internet-Draft TLS 1.3 Flows February 2014
present, this is an error and the server MUST fail with a fatal
"unexpected_message" alert.
Once the server has generated the keys, it MUST process the client's
EncryptedExtensions, which contains any extensions it wants
protected. The EncryptedExtensions MAY contain an Anti-Replay Token
(ART) (Section 6.4.6), which may either be valid or invalid.
6.2.2.2.1. Missing or Invalid ART
If the ART is missing or invalid, then this is a basic 1-RTT
handshake. The server ignores any application_data records as well
as client handshake messages other than those specified in
Section 6.2.1.2 and sends his first flight of messages in the
following order:
o ServerHello
o ServerKeyExchange (Section 6.4.4)
o ChangeCipherSpec
o EncryptedExtensions (Section 6.4.2)
o Certificate*
o CertificateRequest*
o ServerParameters* Section 6.4.5
o CertificateVerify* (if Certificate provided)
o Finished [[TODO:AlmostFinished??]]
The use of the CertificateVerify is new in this context. In prior
versions of TLS, the CertificateVerify was only used to authenticate
the client. Here it is also used to authenticate the server. This
usage has the side benefit that it authenticates the entire handshake
up to this point, not just the server's key.
Note that everything after the ServerKeyExchange and ChangeCipherSpec
is encrypted, thus this mode provides limited privacy. All
extensions other than those required to establish the cryptographic
parameters MUST be in the EncryptedExtensions, not the ServerHello.
Specifically, it protects the server's certificate (but not SNI) and
the selected ALPN data.
6.2.2.2.2. Valid ART
If the ART is valid, then this is a 0-RTT handshake. The server MUST
verify that the client sent the appropriate handshake messages,
including Certificate and CertificateVerify if required by server
policy, as well as a valid Finished message. The server then
generates and sends its own first flight which is exactly the same as
above but MUST omit the CertificateRequest, since the client MUST
already have provided its certificate if required.
Rescorla Expires August 21, 2014 [Page 16]
Internet-Draft TLS 1.3 Flows February 2014
The EncryptedExtensions MUST include an ART indicator that matches
the client's ART so that the client knows that the 0-RTT handshake
was successful and that the client's application_data was accepted.
The details of how this works are TBD. (See Section 6.4.6.)
The server MUST also process any application_data records in the
client's initial flight.
[[TODO: Open issue: should we require Certificate and
CertificateVerify for 0-RTT handshakes? The client in principle has
the server's parameters, but it would make life more consistent to
have less options and the signature isn't that big a deal any more.
The cost here is the computation and the message size.]]
6.2.3. Client Processing of First Flight
Upon receiving the server's first flight, the client must examine the
server's messages to determine what happened. The client SHOULD
follow an algorithm equivalent to the following.
1. If the server version is 1.2 or below, then follow the processing
rules for [RFC5246].
2. If the server has provided only a ServerHello, ServerKeyExchange,
and ServerHelloDone, then all optimistic key exchange has failed.
Re-send a ClientHello with the provided server key and negotiated
parameters as in Section 6.2.1.2
3. If the server provided a full flight of messages but no anti-
replay token in the EncryptedExtensions then the client needs to
process the messages and send his second flight as described in
Section 6.2.3.1.
4. If the server responds with an anti-replay token as well as a
full flight of messages the handshake is finished and the client
can assume that any data it sent was processed. See
Section 6.2.3.2
5. If the server supplies a ServerParameters message, the client
SHOULD remember those parameters for use with future handshakes
and forget any previous ServerParameters for this server. The
ServerParameters are not used for this connection.
6.2.3.1. Successful first Flight But No Anti-Replay
If the server's first flight is complete but has no anti-replay
token, then the handshake is not quite complete: the client
processes the messages and generates its second flight, consisting
of:
Rescorla Expires August 21, 2014 [Page 17]
Internet-Draft TLS 1.3 Flows February 2014
o ChangeCipherSpec (to indicate either the key change)
o Certificate and CertificateVerify (if client authentication was
requested)
o Finished
At this point, the client can start sending application_data. If any
application data was sent with the original ClientHello, the server
will have discarded it and it must be retransmitted.
[[OPEN ISSUE: Do we need a final Finished from the server. The only
thing it does is confirm the server's receipt of the client
certificate, but at the cost of an RT if the client actually checks
it.]]
6.2.3.2. Complete 0-RTT Handshake
If the server has provided an anti-replay token that matches the
client's, the handshake is complete. The client MUST then send a
ChangeCipherSpec and Finished to acknowledge the new key provided by
the server in the ServerKeyExchange. [[OPEN ISSUE: Can we remove
Finished here?]]
6.2.4. Session Resumption
While resumption adds significant complexity, there are going to be
low-end devices which still need to support resumption. This is
particularly relevant for the Internet-Of-Things type devices. Note
that this question is orthogonal to the non-resumed handshake flows.
[TODO: This section still needs to be written depending on if people
want to do resumption. It should be straightforward.]
6.3. Example Flows
Rescorla Expires August 21, 2014 [Page 18]
Internet-Draft TLS 1.3 Flows February 2014
Client Server
ClientHello -------->
ServerHello
ServerKeyExchange
<-------- ServerHelloDone
ClientHello
+ PredictedParameters
ClientKeyExchange
[ChangeCipherSpec]
{EncryptedExtensions} --------->
ServerHello
[ChangeCipherSpec]
{EncryptedExtensions}
{Certificate*}
{CertificateRequest*}
{ServerParameters*}
{CertificateVerify*}
<--------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} --------->
<--------- {Finished ???}
Figure 4: Non-Optimistic Handshake
[TODO: Can we remove the first finished rather than the second
finished. Could we remove a RT.]]
Rescorla Expires August 21, 2014 [Page 19]
Internet-Draft TLS 1.3 Flows February 2014
Client Server
ClientHello
+ PredictedParameters
ClientKeyExchange
[ChangeCipherSpec]
{EncryptedExtensions
+ AntiReplayToken}
{Certificate*}
{CertificateVerify*}
{Finished}
{ApplicationData} --------->
ServerHello
ServerKeyExchange
[ChangeCipherSpec]
{EncryptedExtensions
+ AntiReplayToken}
{Certificate*}
{CertificateRequest*}
{ServerParameters*}
{CertificateVerify*}
<--------- {Finished}
{[ChangeCipherSpec]}
{Finished???} --------->
Figure 5: Handshake With Anti-Replay
6.4. New/Modified Messages
6.4.1. EarlyData Extension
In order to comply with TLS 1.2, any messages which we wish to be in
the client's first flight must be packaged as extensions to the
ClientHello. The EarlyData extension is usable for this purpose.
struct {
TLSCipherText messages<5 .. 2^24-1>;
} EarlyDataExtension;
The client may include no more than one EarlyData extension in its
ClientHello. The extension simply contains the TLS records which
would otherwise have been included in the client's first flight. Any
data included in EarlyData is not integrated into the handshake
hashes directly. Instead, it is hashed in as marshalled into the
extension. Note that this may include application_data traffic.
Because this is an extension, the server is explicitly permitted to
ignore these messages and the client must be prepared to continue
properly. However, TLS 1.3 servers SHOULD process any messages in
Rescorla Expires August 21, 2014 [Page 20]
Internet-Draft TLS 1.3 Flows February 2014
the EarlyData extension, though it may not ultimately be able to use
them.
[[Open Issue: in this version, we never send EarlyData unless we
have evidence that the server is TLS 1.3. In principle we might be
able to just send the messages directly, but what about middleboxes
which have appeared in the path since we discovered that. In that
case, we would need a ClientHelloDone]]
6.4.2. EncryptedExtensions
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
The EncryptedExtensions message simply contains any extensions which
should be protected, i.e., any which are not needed to establish the
cryptographic context. It MUST only be sent after the switch to
protected operations. See Appendix B for guidance on which
extensions go where.
6.4.3. PredictedParameters
struct {
ProtocolVersion version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque server_key_label<0..2^16-1>;
Extension extensions<0..2^16-1>;
} PredictedParameters;
The PredictedParameters message contains the clients prediction of
the parameters that the server will select and therefore which the
client is optimistically using for the connection. The values here
are:
version
The negotiated TLS version.
cipher_suite
The selected cipher suite.
compression_method
Rescorla Expires August 21, 2014 [Page 21]
Internet-Draft TLS 1.3 Flows February 2014
The negotiated TLS compression method. [[OPEN ISSUE: Should we
just remove compression.]].
server_key_label
The label for the server key (provided in a Section 6.4.5
message).
extensions
Any extensions which form part of the SecurityParameters, such as
"truncated_hmac" or "max_fragment_length".
6.4.4. ServerKeyExchange
In the existing TLS handshake, if the server is authenticated (the
most common case) the ServerKeyExchange contains a digital signature
over the server's ephemeral public keying material. However, this
obviously leaks the identity that the server is using; even if the
server certificate is encrypted an attacker can simply iterate over
the server's certificates until it finds one that allows verification
of the signature (at least in the case where each SNI uses a
different certificate).
In order to remove this issue, we remove the signature from the
ServerKeyExchange and use the CertificateVerify message (which was
previously only used for client certificate verification).
struct {
select (KeyExchangeAlgorithm) {
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
case ec_diffie_hellman:
ServerECDHParams params;
}
} ServerKeyExchange;
Rescorla Expires August 21, 2014 [Page 22]
Internet-Draft TLS 1.3 Flows February 2014
6.4.5. ServerParameters
struct {
opaque label<0..2^16-1>;
uint32 lifetime;
select (KeyExchangeAlgorithm) {
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
case ec_diffie_hellman:
ServerECDHParams params;
};
} ServerParameters;
The ServerParameters message is used to indicate the server's "long-
term" (really medium-term) parameters, specifically a DHE/ECDHE key
pair which can potentially be used by the client for future
connections, thus shortcutting the round-trip to discover the
server's DH key. [[OPEN ISSUE: Should we add other policy-like
stuff like whether we expect client auth? This would make the
behavior expected for 0-RTT handshakes explicit rather than implicit.
I am leaning towards this.]] The params are the same fields as in
the ServerKeyExchange [[OPEN ISSUE: Merge these?]]. The other
fields are as follows.
label
A label for these parameters which can be re-sent by the client in
the PredictedParameters messages. Note that this is left
potentially quite large to allow the server to pack data into it,
though this may have an impact on performance.
lifetime
The expected useful lifetime of these parameters in seconds from
now.
6.4.6. Anti-Replay Token
There are a number of potential mechanisms for detecting replay on
the server side. Generally all of them require the server to give
the client some identifier which is later replayed to the server to
help it recover state and detect replays.
This section lists the main ones I know of:
Rescorla Expires August 21, 2014 [Page 23]
Internet-Draft TLS 1.3 Flows February 2014
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
0-RTT handshake.
As an example, consider the mechanism used by Snap Start, which
assumes roughly synchronized clocks between the client and the
server. The server maintains a list of all the ClientRandom values
offered within a given time window (recall that the TLS ClientRandom
value contains a timestamp) and rejects any ClientRandoms which
appear to be outside that window. The server also provides the
client with an 8-byte "orbit" value (which would serve here as the
Anti-Replay Token) which can be used to separate the anti-replay
lists from distinct servers. If a server sees a duplicate
ClientRandom, one from a different orbit, or one from a time outside
the window, it rejects it and forces the client to complete the
handshake with a fresh server nonce.
If we were to follow this model, we would have something like the
following. [[OPEN ISSUE: The following is extremely handwavy and
presented as one possibility. It needs to be gone over more
carefully.]]
struct {
opaque orbit[8];
uint64 time;
select (ConnectionEnd) {
case Client:
opaque certificate_hash;
case Server:
; // Empty
};
} AntiReplayToken;
These fields would be something like:
Rescorla Expires August 21, 2014 [Page 24]
Internet-Draft TLS 1.3 Flows February 2014
orbit
An arbitrary 64-bit quantity selected by the server.
time
The current time in microseconds since the UNIX epoch.
certificate_hash
A digest of the server's expected Certificate message using the
Hash from the PRF. This would need to be checked by the server to
verify that the client is trying to talk to the right server.
[[OPEN ISSUE: This still seems like kind of a mess.]]
7. Backward 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.
8. Security Considerations
Everything in this document needs further analysis to determine if it
is OK. Comments on some known issues below.
8.1. Limits Of Identity Hiding
If the SNI and ALPN information are only sent encrypted (i.e., are
not included in an initial unencrypted ClientHello) then they are
secure from a passive attacker, and thus so is the server's identity.
An active attacker can, however, force the client to reveal them by
simulating a non-optimistic handshake (even if the client has a
previous ServerParameters value) and sending his own DHE/ECDHE share,
thus eliciting a version of the extensions encrypted to him. This
cannot be done transparently to the client, however, since it will
generate a handshake failure.
By contrast, since the server authenticates first and the client only
encrypts its certificate under keying material which has been
authenticated by the server, the attacker does not learn the client's
identity.
8.2. Partial PFS
If the client opts to use an optimistic handshake, any messages the
client sends before the ServerKeyExchange will not have PFS, as they
Rescorla Expires August 21, 2014 [Page 25]
Internet-Draft TLS 1.3 Flows February 2014
will be encrypted with a key which is necessarily somewhat long-term.
The server can of course limit the exposure of the data by limiting
the lifetime of keys, but at the cost of reducing the success
probability of optimistic handshakes.
Servers can opt to always require PFS by never supplying
ServerParameters, thus forcing the client to go through a full
handshake. Clients can opt to always require PFS by never offering
an optimistic handshake.
9. Acknowledgements
This document borrows ideas and/or has benefitted from feedback from
a large number of people, including Dan Boneh, Wan-Teh Chang, Steve
Checkoway, Matt Green, Cullen Jennings, Adam Langley, Nagendra
Modadugu, Bodo Moeller, Andrei Popov, Marsh Ray, Hovav Shacham,
Martin Thomson, and Brian Smith.
10. References
10.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-16 (work in progress),
February 2014.
[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.
10.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]
Rescorla Expires August 21, 2014 [Page 26]
Internet-Draft TLS 1.3 Flows February 2014
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-04
(work in progress), January 2014.
[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. Design Rationale
This section attempts to explain some of the design decisions in this
document.
A.1. EarlyData Extension
In TLS 1.2, the client's first flight consists solely of the
ClientHello message. In TLS 1.3, we allow other handshake messages,
but these are likely to cause incompatibilities. Specifically, if
the client sends other messages besides the ClientHello it will cause
handshake failures. In prior versions of this document, this was
necessary because the client could optimistically send messages even
if it did not know that the server supported TLS 1.3. In the current
version of the document, this is not possible, but there may still be
intermediaries in the path which enforce pre TLS 1.3 semantics.
These intermediaries may have been added after the client's last
contact with the server. For that reason, we continue to keep these
extra messages in an extension. This may change if research
indicates it is unnecessary.
A.2. Always Encrypt Client Parameters
If there is a commonly-recognized DHE/ECDHE group, the client can
just offer its DHE/ECDHE key in the ClientHello and hope that the
server supports it, as shown in Figure 6. This mode would protect
only the server's response to the client but not the client's
extensions, etc. We want to have a mode which does protect the
client's extensions (principally SNI) and supporting both modes adds
complexity, so we opted not to provide the partially-encrypted mode.
If the WG wanted to add it, we could do so.
Rescorla Expires August 21, 2014 [Page 27]
Internet-Draft TLS 1.3 Flows February 2014
A.3. Always Restarting Non-Optimistic Handshakes
The non-optimistic handshake shown in Figure 4 requires the client to
restart with a new ClientHello even if the server could actually have
sent a full first flight as in TLS 1.2. This case could occur either
because the client sent SNI and ALPN for backwards compatibility or
because the server doesn't have behavior contingent on SNI/ALPN. The
result is that the handshake takes an extra round trip when compared
to TLS 1.2 with False Start.
The alternative would be to allow a server to do a TLS 1.2-style
handshake if the client had supplied enough information to do so
(though we could encrypt the client's Certificate if we chose). This
would shorten the round trip time in the case where the client and
server had no previous contact (though with the known security
restrictions of The major argument against this alternative is that
it is yet another mode in an already complex protocol.
A.4. Still TODO...
[[TODO: Explain the following]]
o Server-side parameter selection versus client-side parameter
selection.
o Public semi-static server parameters versus client-specific
parameters.
o Correction instead of negotiation
Appendix B. Summary of Existing Extensions
Many of the flows in this document have Extensions appear both both
in the clear and encrypted. This section attempts to provide a
first-cut proposal (in table form) of which should appear where.
Rescorla Expires August 21, 2014 [Page 28]
Internet-Draft TLS 1.3 Flows February 2014
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.
Appendix C. Non-recommended Flows
The flow below is the only one in which we don't protect client
Rescorla Expires August 21, 2014 [Page 29]
Internet-Draft TLS 1.3 Flows February 2014
extensions. It complicates things and doesn't seem to meet our goals
in terms of protecting that sort of information from traffic
analysis.
Client Server
ClientHello
+ ClientKeyExchange --------->
ServerHello
[ChangeCipherSpec]
{EncryptedServerHello}
{Certificate*}
{CertificateRequest*}
{ServerParameters*}
{CertificateVerify*}
<--------- {Finished}
[ChangeCipherSpec]
{Certificate*}
{CertificateVerify*}
{Finished} --------->
<--------- {Finished ???}
Figure 6: Handshake With Known Group
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 August 21, 2014 [Page 30]
