[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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


   This document sketches some potential new handshake flows for TLS

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  No Knowledge . . . . . . . . . . . . . . . . . . . 12  Server Keying Material . . . . . . . . . . . . . . 13  Anti-Replay Token  . . . . . . . . . . . . . . . . 13
       6.2.2.  Server Behavior For First Flight . . . . . . . . . . . 14  Non-Optimistic Handshakes  . . . . . . . . . . . . 15  Predicted Parameters Correct . . . . . . . . . . . 15
       6.2.3.  Client Processing of First Flight  . . . . . . . . . . 17  Successful first Flight But No Anti-Replay . . . . 17  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


   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
   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                  -------->
                                      <--------      ServerHelloDone
         {Finished}                   -------->
                                      <--------           {Finished}
         {Application Data}           <------->   {Application Data}

                     Figure 1: TLS 1.2 Full Handshake

         Client                                                Server

         ClientHello                   -------->
                                       <--------           {Finished}
         {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                  -------->
                                      <--------      ServerHelloDone
         {Application Data}           -------->

                                      <--------           {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

   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,

   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

   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

   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

   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

   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

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

          + PredictedParameters
            {EncryptedExtensions}     --------->
                                      <---------          {Finished}
            {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.  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

   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

   In either case, a TLS 1.3 server will respond to this message with a
   ServerKeyExchange, as in Section  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.  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

   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
   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 then we could use that ServerRandom, but this
   just makes the security properties more confusing.]]  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  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
   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  Otherwise, this
       is a successful optimistic handshake, so proceed as in
   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  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, 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  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.]]  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.  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 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.  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
   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
   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
   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.  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

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
   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.]]  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                  -------->
                                      <--------      ServerHelloDone
          + PredictedParameters
            {EncryptedExtensions}     --------->
                                      <---------          {Finished}
            {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

          + PredictedParameters
             + AntiReplayToken}
            {ApplicationData}        --------->
                                                  + AntiReplayToken}
                                      <---------          {Finished}
            {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

   [[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

      The negotiated TLS version.

      The selected cipher suite.


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.]].

      The label for the server key (provided in a Section 6.4.5

      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.

      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.

      The expected useful lifetime of these parameters in seconds from

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

   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

      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

      An arbitrary 64-bit quantity selected by the server.

      The current time in microseconds since the UNIX epoch.

      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

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

              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

              Langley, A., "Transport Layer Security (TLS) Next Protocol
              Negotiation Extension", draft-agl-tls-nextprotoneg-04
              (work in progress), May 2012.

              Langley, A., "Transport Layer Security (TLS) Snap Start",
              draft-agl-tls-snapstart-00 (work in progress), June 2010.


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.

              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.

              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

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
   o  Public semi-static server parameters versus client-specific
   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

         Client                                               Server

          + ClientKeyExchange         --------->
                                      <---------          {Finished}
          {Finished}                --------->
                                      <---------      {Finished ???}

                   Figure 6: Handshake With Known Group

Author's Address

   Eric Rescorla
   2064 Edgewood Drive
   Palo Alto, CA  94303

   Phone:  +1 650 678 2350
   Email:  ekr@rtfm.com

Rescorla                 Expires August 21, 2014               [Page 30]

Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/