The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-21

quot; alert.

   The padding sent is automatically verified by the record protection
   mechanism; upon successful decryption of a
   TLSCiphertext.encrypted_record, the receiving implementation scans
   the field from the end toward the beginning until it finds a non-zero
   octet.  This non-zero octet is the content type of the message.  This
   padding scheme was selected because it allows padding of any
   encrypted TLS record by an arbitrary size (from zero up to TLS record
   size limits) without introducing new content types.  The design also
   enforces all-zero padding octets, which allows for quick detection of
   padding errors.

   Implementations MUST limit their scanning to the cleartext returned
   from the AEAD decryption.  If a receiving implementation does not
   find a non-zero octet in the cleartext, it MUST terminate the
   connection with an "unexpected_message" alert.

   The presence of padding does not change the overall record size
   limitations - the full encoded TLSInnerPlaintext MUST not exceed 2^14
   octets.  If the maximum fragment length is reduced, as for example by
   the max_fragment_length extension from [RFC6066], then the reduced
   limit applies to the full plaintext, including the padding.

   Selecting a padding policy that suggests when and how much to pad is
   a complex topic and is beyond the scope of this specification.  If

Rescorla                 Expires January 4, 2018               [Page 79]
Internet-Draft                     TLS                         July 2017

   the application layer protocol on top of TLS has its own padding, it
   may be preferable to pad application_data TLS records within the
   application layer.  Padding for encrypted handshake and alert TLS
   records must still be handled at the TLS layer, though.  Later
   documents may define padding selection algorithms or define a padding
   policy request mechanism through TLS extensions or some other means.

5.5.  Limits on Key Usage

   There are cryptographic limits on the amount of plaintext which can
   be safely encrypted under a given set of keys.  [AEAD-LIMITS]
   provides an analysis of these limits under the assumption that the
   underlying primitive (AES or ChaCha20) has no weaknesses.
   Implementations SHOULD do a key update as described in Section 4.6.3
   prior to reaching these limits.

   For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be
   encrypted on a given connection while keeping a safety margin of
   approximately 2^-57 for Authenticated Encryption (AE) security.  For
   ChaCha20/Poly1305, the record sequence number would wrap before the
   safety limit is reached.

6.  Alert Protocol

   One of the content types supported by the TLS record layer is the
   alert type.  Like other messages, alert messages are encrypted as
   specified by the current connection state.

   Alert messages convey a description of the alert and a legacy field
   that conveyed the severity of the message in previous versions of
   TLS.  In TLS 1.3, the severity is implicit in the type of alert being
   sent, and the 'level' field can safely be ignored.  The
   "close_notify" alert is used to indicate orderly closure of the
   connection.  Upon receiving such an alert, the TLS implementation
   SHOULD indicate end-of-data to the application.

   Error alerts indicate abortive closure of the connection (see
   Section 6.2).  Upon receiving an error alert, the TLS implementation
   SHOULD indicate an error to the application and MUST NOT allow any
   further data to be sent or received on the connection.  Servers and
   clients MUST forget keys and secrets associated with a failed
   connection.  Stateful implementations of tickets (as in many clients)
   SHOULD discard tickets associated with failed connections.

   All the alerts listed in Section 6.2 MUST be sent as fatal and MUST
   be treated as fatal regardless of the AlertLevel in the message.
   Unknown alert types MUST be treated as fatal.

Rescorla                 Expires January 4, 2018               [Page 80]
Internet-Draft                     TLS                         July 2017

   Note: TLS defines two generic alerts (see Section 6) to use upon
   failure to parse a message.  Peers which receive a message which
   cannot be parsed according to the syntax (e.g., have a length
   extending beyond the message boundary or contain an out-of-range
   length) MUST terminate the connection with a "decode_error" alert.
   Peers which receive a message which is syntactically correct but
   semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
   MUST terminate the connection with an "illegal_parameter" alert.

      enum { warning(1), fatal(2), (255) } AlertLevel;

      enum {
          close_notify(0),
          unexpected_message(10),
          bad_record_mac(20),
          record_overflow(22),
          handshake_failure(40),
          bad_certificate(42),
          unsupported_certificate(43),
          certificate_revoked(44),
          certificate_expired(45),
          certificate_unknown(46),
          illegal_parameter(47),
          unknown_ca(48),
          access_denied(49),
          decode_error(50),
          decrypt_error(51),
          protocol_version(70),
          insufficient_security(71),
          internal_error(80),
          inappropriate_fallback(86),
          user_canceled(90),
          missing_extension(109),
          unsupported_extension(110),
          certificate_unobtainable(111),
          unrecognized_name(112),
          bad_certificate_status_response(113),
          bad_certificate_hash_value(114),
          unknown_psk_identity(115),
          certificate_required(116),
          no_application_protocol(120),
          (255)
      } AlertDescription;

      struct {
          AlertLevel level;
          AlertDescription description;
      } Alert;

Rescorla                 Expires January 4, 2018               [Page 81]
Internet-Draft                     TLS                         July 2017

6.1.  Closure Alerts

   The client and the server must share knowledge that the connection is
   ending in order to avoid a truncation attack.

   close_notify  This alert notifies the recipient that the sender will
      not send any more messages on this connection.  Any data received
      after a closure MUST be ignored.

   user_canceled  This alert notifies the recipient that the sender is
      canceling the handshake for some reason unrelated to a protocol
      failure.  If a user cancels an operation after the handshake is
      complete, just closing the connection by sending a "close_notify"
      is more appropriate.  This alert SHOULD be followed by a
      "close_notify".  This alert is generally a warning.

   Either party MAY initiate a close by sending a "close_notify" alert.
   Any data received after a closure alert MUST be ignored.  If a
   transport-level close is received prior to a "close_notify", the
   receiver cannot know that all the data that was sent has been
   received.

   Each party MUST send a "close_notify" alert before closing the write
   side of the connection, unless some other fatal alert has been
   transmitted.  The other party MUST respond with a "close_notify"
   alert of its own and close down the connection immediately,
   discarding any pending writes.  The initiator of the close need not
   wait for the responding "close_notify" alert before closing the read
   side of the connection.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation MUST receive the responding
   "close_notify" alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding "close_notify".  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

   Note: It is assumed that closing a connection reliably delivers
   pending data before destroying the transport.

Rescorla                 Expires January 4, 2018               [Page 82]
Internet-Draft                     TLS                         July 2017

6.2.  Error Alerts

   Error handling in the TLS Handshake Protocol is very simple.  When an
   error is detected, the detecting party sends a message to its peer.
   Upon transmission or receipt of a fatal alert message, both parties
   MUST immediately close the connection.

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.  In the rest of
   this specification, when the phrases "terminate the connection" and
   "abort the handshake" are used without a specific alert it means that
   the implementation SHOULD send the alert indicated by the
   descriptions below.  The phrases "terminate the connection with a X
   alert" and "abort the handshake with a X alert" mean that the
   implementation MUST send alert X if it sends any alert.  All alerts
   defined in this section below, as well as all unknown alerts, are
   universally considered fatal as of TLS 1.3 (see Section 6).  The
   implementation SHOULD provide a way to facilitate logging the sending
   and receiving of alerts.

   unexpected_message  An inappropriate message (e.g., the wrong
      handshake message, premature application data, etc.) was received.
      This alert should never be observed in communication between
      proper implementations.

   bad_record_mac  This alert is returned if a record is received which
      cannot be deprotected.  Because AEAD algorithms combine decryption
      and verification, and also to avoid side channel attacks, this
      alert is used for all deprotection failures.  This alert should
      never be observed in communication between proper implementations,
      except when messages were corrupted in the network.

   record_overflow  A TLSCiphertext record was received that had a
      length more than 2^14 + 256 bytes, or a record decrypted to a
      TLSPlaintext record with more than 2^14 bytes.  This alert should
      never be observed in communication between proper implementations,
      except when messages were corrupted in the network.

   handshake_failure  Receipt of a "handshake_failure" alert message
      indicates that the sender was unable to negotiate an acceptable
      set of security parameters given the options available.

   bad_certificate  A certificate was corrupt, contained signatures that
      did not verify correctly, etc.

   unsupported_certificate  A certificate was of an unsupported type.

Rescorla                 Expires January 4, 2018               [Page 83]
Internet-Draft                     TLS                         July 2017

   certificate_revoked  A certificate was revoked by its signer.

   certificate_expired  A certificate has expired or is not currently
      valid.

   certificate_unknown  Some other (unspecified) issue arose in
      processing the certificate, rendering it unacceptable.

   illegal_parameter  A field in the handshake was incorrect or
      inconsistent with other fields.  This alert is used for errors
      which conform to the formal protocol syntax but are otherwise
      incorrect.

   unknown_ca  A valid certificate chain or partial chain was received,
      but the certificate was not accepted because the CA certificate
      could not be located or could not be matched with a known trust
      anchor.

   access_denied  A valid certificate or PSK was received, but when
      access control was applied, the sender decided not to proceed with
      negotiation.

   decode_error  A message could not be decoded because some field was
      out of the specified range or the length of the message was
      incorrect.  This alert is used for errors where the message does
      not conform to the formal protocol syntax.  This alert should
      never be observed in communication between proper implementations,
      except when messages were corrupted in the network.

   decrypt_error  A handshake (not record-layer) cryptographic operation
      failed, including being unable to correctly verify a signature or
      validate a Finished message or a PSK binder.

   protocol_version  The protocol version the peer has attempted to
      negotiate is recognized but not supported. (see Appendix D)

   insufficient_security  Returned instead of "handshake_failure" when a
      negotiation has failed specifically because the server requires
      parameters more secure than those supported by the client.

   internal_error  An internal error unrelated to the peer or the
      correctness of the protocol (such as a memory allocation failure)
      makes it impossible to continue.

   inappropriate_fallback  Sent by a server in response to an invalid
      connection retry attempt from a client (see [RFC7507]).

Rescorla                 Expires January 4, 2018               [Page 84]
Internet-Draft                     TLS                         July 2017

   missing_extension  Sent by endpoints that receive a hello message not
      containing an extension that is mandatory to send for the offered
      TLS version or other negotiated parameters.

   unsupported_extension  Sent by endpoints receiving any hello message
      containing an extension known to be prohibited for inclusion in
      the given hello message, or including any extensions in a
      ServerHello or Certificate not first offered in the corresponding
      ClientHello.

   certificate_unobtainable  Sent by servers when unable to obtain a
      certificate from a URL provided by the client via the
      "client_certificate_url" extension (see [RFC6066]).

   unrecognized_name  Sent by servers when no server exists identified
      by the name provided by the client via the "server_name" extension
      (see [RFC6066]).

   bad_certificate_status_response  Sent by clients when an invalid or
      unacceptable OCSP response is provided by the server via the
      "status_request" extension (see [RFC6066]).

   bad_certificate_hash_value  Sent by servers when a retrieved object
      does not have the correct hash provided by the client via the
      "client_certificate_url" extension (see [RFC6066]).

   unknown_psk_identity  Sent by servers when PSK key establishment is
      desired but no acceptable PSK identity is provided by the client.
      Sending this alert is OPTIONAL; servers MAY instead choose to send
      a "decrypt_error" alert to merely indicate an invalid PSK
      identity.

   certificate_required  Sent by servers when a client certificate is
      desired but none was provided by the client.

   no_application_protocol  Sent by servers when a client
      "application_layer_protocol_negotiation" extension advertises
      protocols that the server does not support (see [RFC7301]).

   New Alert values are assigned by IANA as described in Section 11.

7.  Cryptographic Computations

   The TLS handshake establishes one or more input secrets which are
   combined to create the actual working keying material, as detailed
   below.  The key derivation process incorporates both the input
   secrets and the handshake transcript.  Note that because the
   handshake transcript includes the random values from the Hello

Rescorla                 Expires January 4, 2018               [Page 85]
Internet-Draft                     TLS                         July 2017

   messages, any given handshake will have different traffic secrets,
   even if the same input secrets are used, as is the case when the same
   PSK is used for multiple connections

7.1.  Key Schedule

   The key derivation process makes use of the HKDF-Extract and HKDF-
   Expand functions as defined for HKDF [RFC5869], as well as the
   functions defined below:

       HKDF-Expand-Label(Secret, Label, HashValue, Length) =
            HKDF-Expand(Secret, HkdfLabel, Length)

       Where HkdfLabel is specified as:

       struct {
           uint16 length = Length;
           opaque label<7..255> = "tls13 " + Label;
           opaque hash_value<0..255> = HashValue;
       } HkdfLabel;

       Derive-Secret(Secret, Label, Messages) =
            HKDF-Expand-Label(Secret, Label,
                              Transcript-Hash(Messages), Hash.length)

   The Hash function used by Transcript-Hash and HKDF is the cipher
   suite hash algorithm.  Hash.length is its output length in bytes.
   Messages are the concatenation of the indicated handshake messages,
   including the handshake message type and length fields, but not
   including record layer headers.  Note that in some cases a zero-
   length HashValue (indicated by "") is passed to HKDF-Expand-Label.

   Note: with common hash functions, any label longer than 12 characters
   requires an additional iteration of the hash function to compute.
   The labels in this specification have all been chosen to fit within
   this limit.

   Given a set of n InputSecrets, the final "master secret" is computed
   by iteratively invoking HKDF-Extract with InputSecret_1,
   InputSecret_2, etc.  The initial secret is simply a string of
   Hash.length zero bytes.  Concretely, for the present version of TLS
   1.3, secrets are added in the following order:

   -  PSK (a pre-shared key established externally or derived from the
      resumption_master_secret value from a previous connection)

   -  (EC)DHE shared secret (Section 7.4)

Rescorla                 Expires January 4, 2018               [Page 86]
Internet-Draft                     TLS                         July 2017

   This produces a full key derivation schedule shown in the diagram
   below.  In this diagram, the following formatting conventions apply:

   -  HKDF-Extract is drawn as taking the Salt argument from the top and
      the IKM argument from the left.

   -  Derive-Secret's Secret argument is indicated by the incoming
      arrow.  For instance, the Early Secret is the Secret for
      generating the client_early_traffic_secret.

                 0
                 |
                 v
   PSK ->  HKDF-Extract = Early Secret
                 |
                 +-----> Derive-Secret(.,
                 |                     "ext binder" |
                 |                     "res binder",
                 |                     "")
                 |                     = binder_key
                 |
                 +-----> Derive-Secret(., "c e traffic",
                 |                     ClientHello)
                 |                     = client_early_traffic_secret
                 |
                 +-----> Derive-Secret(., "e exp master",
                 |                     ClientHello)
                 |                     = early_exporter_master_secret
                 v
           Derive-Secret(., "derived", "")
                 |
                 v
(EC)DHE -> HKDF-Extract = Handshake Secret
                 |
                 +-----> Derive-Secret(., "c hs traffic",
                 |                     ClientHello...ServerHello)
                 |                     = client_handshake_traffic_secret
                 |
                 +-----> Derive-Secret(., "s hs traffic",
                 |                     ClientHello...ServerHello)
                 |                     = server_handshake_traffic_secret
                 v
           Derive-Secret(., "derived", "")
                 |
                 v
      0 -> HKDF-Extract = Master Secret
                 |
                 +-----> Derive-Secret(., "c ap traffic",

Rescorla                 Expires January 4, 2018               [Page 87]
Internet-Draft                     TLS                         July 2017

                 |                     ClientHello...server Finished)
                 |                     = client_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "s ap traffic",
                 |                     ClientHello...server Finished)
                 |                     = server_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "exp master",
                 |                     ClientHello...server Finished)
                 |                     = exporter_master_secret
                 |
                 +-----> Derive-Secret(., "res master",
                                       ClientHello...client Finished)
                                       = resumption_master_secret

   The general pattern here is that the secrets shown down the left side
   of the diagram are just raw entropy without context, whereas the
   secrets down the right side include handshake context and therefore
   can be used to derive working keys without additional context.  Note
   that the different calls to Derive-Secret may take different Messages
   arguments, even with the same secret.  In a 0-RTT exchange, Derive-
   Secret is called with four distinct transcripts; in a 1-RTT-only
   exchange with three distinct transcripts.

   If a given secret is not available, then the 0-value consisting of a
   string of Hash.length zero bytes is used.  Note that this does not
   mean skipping rounds, so if PSK is not in use Early Secret will still
   be HKDF-Extract(0, 0).  For the computation of the binder_secret, the
   label is "ext binder" for external PSKs (those provisioned outside of
   TLS) and "res binder" for resumption PSKs (those provisioned as the
   resumption master secret of a previous handshake).  The different
   labels prevent the substitution of one type of PSK for the other.

   There are multiple potential Early Secret values depending on which
   PSK the server ultimately selects.  The client will need to compute
   one for each potential PSK; if no PSK is selected, it will then need
   to compute the early secret corresponding to the zero PSK.

   Once all the values which are to be derived from a given secret have
   been computed, that secret SHOULD be erased.

7.2.  Updating Traffic Keys and IVs

   Once the handshake is complete, it is possible for either side to
   update its sending traffic keys using the KeyUpdate handshake message
   defined in Section 4.6.3.  The next generation of traffic keys is
   computed by generating client_/server_application_traffic_secret_N+1
   from client_/server_application_traffic_secret_N as described in this

Rescorla                 Expires January 4, 2018               [Page 88]
Internet-Draft                     TLS                         July 2017

   section then re-deriving the traffic keys as described in
   Section 7.3.

   The next-generation application_traffic_secret is computed as:

       application_traffic_secret_N+1 =
           HKDF-Expand-Label(application_traffic_secret_N,
                             "traffic upd", "", Hash.length)

   Once client/server_application_traffic_secret_N+1 and its associated
   traffic keys have been computed, implementations SHOULD delete
   client_/server_application_traffic_secret_N and its associated
   traffic keys.

7.3.  Traffic Key Calculation

   The traffic keying material is generated from the following input
   values:

   -  A secret value

   -  A purpose value indicating the specific value being generated

   -  The length of the key

   The traffic keying material is generated from an input traffic secret
   value using:

    [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
    [sender]_write_iv  = HKDF-Expand-Label(Secret, "iv" , "", iv_length)

   [sender] denotes the sending side.  The Secret value for each record
   type is shown in the table below.

       +-------------------+---------------------------------------+
       | Record Type       | Secret                                |
       +-------------------+---------------------------------------+
       | 0-RTT Application | client_early_traffic_secret           |
       |                   |                                       |
       | Handshake         | [sender]_handshake_traffic_secret     |
       |                   |                                       |
       | Application Data  | [sender]_application_traffic_secret_N |
       +-------------------+---------------------------------------+

   All the traffic keying material is recomputed whenever the underlying
   Secret changes (e.g., when changing from the handshake to application
   data keys or upon a key update).

Rescorla                 Expires January 4, 2018               [Page 89]
Internet-Draft                     TLS                         July 2017

7.4.  (EC)DHE Shared Secret Calculation

7.4.1.  Finite Field Diffie-Hellman

   For finite field groups, a conventional Diffie-Hellman computation is
   performed.  The negotiated key (Z) is converted to a byte string by
   encoding in big-endian and padded with zeros up to the size of the
   prime.  This byte string is used as the shared secret in the key
   schedule as specified above.

   Note that this construction differs from previous versions of TLS
   which remove leading zeros.

7.4.2.  Elliptic Curve Diffie-Hellman

   For secp256r1, secp384r1 and secp521r1, ECDH calculations (including
   parameter and key generation as well as the shared secret
   calculation) are performed according to [IEEE1363] using the ECKAS-
   DH1 scheme with the identity map as key derivation function (KDF), so
   that the shared secret is the x-coordinate of the ECDH shared secret
   elliptic curve point represented as an octet string.  Note that this
   octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the
   Field Element to Octet String Conversion Primitive, has constant
   length for any given field; leading zeros found in this octet string
   MUST NOT be truncated.

   (Note that this use of the identity KDF is a technicality.  The
   complete picture is that ECDH is employed with a non-trivial KDF
   because TLS does not directly use this secret for anything other than
   for computing other secrets.)

   ECDH functions are used as follows:

   -  The public key to put into the KeyShareEntry.key_exchange
      structure is the result of applying the ECDH scalar multiplication
      function to the secret key of appropriate length (into scalar
      input) and the standard public basepoint (into u-coordinate point
      input).

   -  The ECDH shared secret is the result of applying the ECDH scalar
      multiplication function to the secret key (into scalar input) and
      the peer's public key (into u-coordinate point input).  The output
      is used raw, with no processing.

   For X25519 and X448, implementations SHOULD use the approach
   specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in

Rescorla                 Expires January 4, 2018               [Page 90]
Internet-Draft                     TLS                         July 2017

   Section 6 of [RFC7748].  If implementers use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].

7.5.  Exporters

   [RFC5705] defines keying material exporters for TLS in terms of the
   TLS pseudorandom function (PRF).  This document replaces the PRF with
   HKDF, thus requiring a new construction.  The exporter interface
   remains the same.

   The exporter value is computed as:

   HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
                     "exporter", Hash(context_value), key_length)

   Where Secret is either the early_exporter_master_secret or the
   exporter_master_secret.  Implementations MUST use the
   exporter_master_secret unless explicitly specified by the
   application.  The early_exporter_master_secret is defined for use in
   settings where an exporter is needed for 0-RTT data.  A separate
   interface for the early exporter is RECOMMENDED, especially on a
   server where a single interface can make the early exporter
   inaccessible.

   If no context is provided, the context_value is zero-length.
   Consequently, providing no context computes the same value as
   providing an empty context.  This is a change from previous versions
   of TLS where an empty context produced a different output to an
   absent context.  As of this document's publication, no allocated
   exporter label is used both with and without a context.  Future
   specifications MUST NOT define a use of exporters that permit both an
   empty context and no context with the same label.  New uses of
   exporters SHOULD provide a context in all exporter computations,
   though the value could be empty.

   Requirements for the format of exporter labels are defined in section
   4 of [RFC5705].

8.  0-RTT and Anti-Replay

   As noted in Section 2.3 and Appendix E.5, TLS does not provide
   inherent replay protections for 0-RTT data.  There are two potential
   threats to be concerned with:

   -  Network attackers who mount a replay attack by simply duplicating
      a flight of 0-RTT data.

Rescorla                 Expires January 4, 2018               [Page 91]
Internet-Draft                     TLS                         July 2017

   -  Network attackers who take advantage of client retry behavior to
      arrange for the server to receive multiple copies of an
      application message.  This threat already exists to some extent
      because clients that value robustness respond to network errors by
      attempting to retry requests.  However, 0-RTT adds an additional
      dimension for any server system which does not maintain globally
      consistent server state.  Specifically, if a server system has
      multiple zones where tickets from zone A will not be accepted in
      zone B, then an attacker can duplicate a ClientHello and early
      data intended for A to both A and B.  At A, the data will be
      accepted in 0-RTT, but at B the server will reject 0-RTT data and
      instead force a full handshake.  If the attacker blocks the
      ServerHello from A, then the client will complete the handshake
      with B and probably retry the request, leading to duplication on
      the server system as a whole.

   The first class of attack can be prevented by the mechanism described
   in this section.  Servers need not permit 0-RTT at all, but those
   which do SHOULD implement either the single-use tickets or
   ClientHello recording techniques described in the following two
   sections.

   The second class of attack cannot be prevented at the TLS layer and
   MUST be dealt with by any application.  Note that any application
   whose clients implement any kind of retry behavior already needs to
   implement some sort of anti-replay defense.

   In normal operation, clients will not know which, if any, of these
   mechanisms servers actually implement and therefore MUST only send
   early data which they are willing to have subject to the attacks
   described in Appendix E.5.

8.1.  Single-Use Tickets

   The simplest form of anti-replay defense is for the server to only
   allow each session ticket to be used once.  For instance, the server
   can maintain a database of all outstanding valid tickets; deleting
   each ticket from the database as it is used.  If an unknown ticket is
   provided, the server would then fall back to a full handshake.

   If the tickets are not self-contained but rather are database keys,
   and the corresponding PSKs are deleted upon use, then connections
   established using one PSK enjoy forward security.  This improves
   security for all 0-RTT data and PSK usage when PSK is used without
   (EC)DHE.

   Because this mechanism requires sharing the session database between
   server nodes in environments with multiple distributed servers, it

Rescorla                 Expires January 4, 2018               [Page 92]
Internet-Draft                     TLS                         July 2017

   may be hard to achieve high rates of successful PSK 0-RTT connections
   when compared to self-encrypted tickets.  Unlike session databases,
   session tickets can successfully do PSK-based session establishment
   even without consistent storage, though when 0-RTT is allowed they
   still require consistent storage for anti-replay of 0-RTT data, as
   detailed in the following section.

8.2.  Client Hello Recording

   An alternative form of anti-replay is to record a unique value
   derived from the ClientHello (generally either the random value or
   the PSK binder) and reject duplicates.  Recording all ClientHellos
   causes state to grow without bound, but a server can instead record
   ClientHellos within a given time window and use the
   "obfuscated_ticket_age" to ensure that tickets aren't reused outside
   that window.

   In order to implement this, when a ClientHello is received, the
   server first verifies the PSK binder as described Section 4.2.10.  It
   then computes the expected_arrival_time as described in the next
   section and rejects 0-RTT if it is outside the recording window,
   falling back to the 1-RTT handshake.

   If the expected arrival time is in the window, then the server checks
   to see if it has recorded a matching ClientHello.  If one is found,
   it either aborts the handshake with an "illegal_parameter" alert or
   accepts the PSK but reject 0-RTT.  If no matching ClientHello is
   found, then it accepts 0-RTT and then stores the ClientHello for as
   long as the expected_arrival_time is inside the window.  Servers MAY
   also implement data stores with false positives, such as Bloom
   filters, in which case they MUST respond to apparent replay by
   rejecting 0-RTT but MUST NOT abort the handshake.

   The server MUST derive the storage key only from validated sections
   of the ClientHello.  If the ClientHello contains multiple PSK
   identities, then an attacker can create multiple ClientHellos with
   different binder values for the less-preferred identity on the
   assumption that the server will not verify it, as recommended by
   Section 4.2.10.  I.e., if the client sends PSKs A and B but the
   server prefers A, then the attacker can change the binder for B
   without affecting the binder for A.  This will cause the ClientHello
   to be accepted, and may casue side effects such as replay cache
   pollution, although any 0-RTT data will not be decryptable because it
   will use different keys.  If the validated binder or the
   ClientHello.random are used as the storage key, then this attack is
   not possible.

Rescorla                 Expires January 4, 2018               [Page 93]
Internet-Draft                     TLS                         July 2017

   Because this mechanism does not require storing all outstanding
   tickets, it may be easier to implement in distributed systems with
   high rates of resumption and 0-RTT, at the cost of potentially weaker
   anti-replay defense because of the difficulty of reliably storing and
   retrieving the received ClientHello messages.  In many such systems,
   it is impractical to have globally consistent storage of all the
   received ClientHellos.  In this case, the best anti-replay protection
   is provided by having a single storage zone be authoritative for a
   given ticket and refusing 0-RTT for that ticket in any other zone.
   This approach prevents simple replay by the attacker because only one
   zone will accept 0-RTT data.  A weaker design is to implement
   separate storage for each zone but allow 0-RTT in any zone.  This
   approach limits the number of replays to once per zone.  Application
   message duplication of course remains possible with either design.

   When implementations are freshly started, they SHOULD reject 0-RTT as
   long as any portion of their recording window overlaps the startup
   time.  Otherwise, they run the risk of accepting replays which were
   originally sent during that period.

   Note: If the client's clock is running much faster than the server's
   then a ClientHello may be received that is outside the window in the
   future, in which case it might be accepted for 1-RTT, causing a
   client retry, and then acceptable later for 0-RTT.  This is another
   variant of the second form of attack described above.

8.3.  Freshness Checks

   Because the ClientHello indicates the time at which the client sent
   it, it is possible to efficiently determine whether a ClientHello was
   likely sent reasonably recently and only accept 0-RTT for such a
   ClientHello, otherwise falling back to a 1-RTT handshake.  This is
   necessary for the ClientHello storage mechanism described in
   Section 8.2 because otherwise the server needs to store an unlimited
   number of ClientHellos and is a useful optimization for single-use
   tickets because it allows efficient rejection of ClientHellos which
   cannot be used for 0-RTT.

   In order to implement this mechanism, a server needs to store the
   time that the server generated the session ticket, offset by an
   estimate of the round trip time between client and server.  I.e.,

       adjusted_creation_time = creation_time + estimated_RTT

   This value can be encoded in the ticket, thus avoiding the need to
   keep state for each outstanding ticket.  The server can determine the
   client's view of the age of the ticket by subtracting the ticket's
   "ticket_age_add value" from the "obfuscated_ticket_age" parameter in

Rescorla                 Expires January 4, 2018               [Page 94]
Internet-Draft                     TLS                         July 2017

   the client's "pre_shared_key" extension.  The server can determine
   the "expected arrival time" of the ClientHello as:

     expected_arrival_time = adjusted_creation_time + clients_ticket_age

   When a new ClientHello is received, the expected_arrival_time is then
   compared against the current server wall clock time and if they
   differ by more than a certain amount, 0-RTT is rejected, though the
   1-RTT handshake can be allowed to complete.

   There are several potential sources of error that might cause
   mismatches between the expected arrival time and the measured time.
   Variations in client and server clock rates are likely to be minimal,
   though potentially with gross time corrections.  Network propagation
   delays are the most likely causes of a mismatch in legitimate values
   for elapsed time.  Both the NewSessionTicket and ClientHello messages
   might be retransmitted and therefore delayed, which might be hidden
   by TCP.  For clients on the Internet, this implies windows on the
   order of ten seconds to account for errors in clocks and variations
   in measurements; other deployment scenarios may have different needs.
   Clock skew distributions are not symmetric, so the optimal tradeoff
   may involve an asymmetric range of permissible mismatch values.

   Note that freshness checking alone is not sufficient to prevent
   replays because it does not detect them during the error window,
   which, depending on bandwidth and system capacity could include
   billions of replays in real-world settings.  In addition, this
   freshness checking is only done at the time the ClientHello is
   received, and not when later early application data records are
   received.  After early data is accepted, records may continue to be
   streamed to the server over a longer time period.

9.  Compliance Requirements

9.1.  Mandatory-to-Implement Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the
   TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
   TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
   [RFC7539] cipher suites.  (see Appendix B.4)

   A TLS-compliant application MUST support digital signatures with
   rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
   CertificateVerify and certificates), and ecdsa_secp256r1_sha256.  A
   TLS-compliant application MUST support key exchange with secp256r1
   (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

Rescorla                 Expires January 4, 2018               [Page 95]
Internet-Draft                     TLS                         July 2017

9.2.  Mandatory-to-Implement Extensions

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the following
   TLS extensions:

   -  Supported Versions ("supported_versions"; Section 4.2.1)

   -  Cookie ("cookie"; Section 4.2.2)

   -  Signature Algorithms ("signature_algorithms"; Section 4.2.3)

   -  Negotiated Groups ("supported_groups"; Section 4.2.6)

   -  Key Share ("key_share"; Section 4.2.7)

   -  Server Name Indication ("server_name"; Section 3 of [RFC6066])

   All implementations MUST send and use these extensions when offering
   applicable features:

   -  "supported_versions" is REQUIRED for all ClientHello messages.

   -  "signature_algorithms" is REQUIRED for certificate authentication.

   -  "supported_groups" is REQUIRED for ClientHello messages using DHE
      or ECDHE key exchange.

   -  "key_share" is REQUIRED for DHE or ECDHE key exchange.

   -  "pre_shared_key" is REQUIRED for PSK key agreement.

   A client is considered to be attempting to negotiate using this
   specification if the ClientHello contains a "supported_versions"
   extension 0x0304 the highest version number contained in its body.
   Such a ClientHello message MUST meet the following requirements:

   -  If not containing a "pre_shared_key" extension, it MUST contain
      both a "signature_algorithms" extension and a "supported_groups"
      extension.

   -  If containing a "supported_groups" extension, it MUST also contain
      a "key_share" extension, and vice versa.  An empty
      KeyShare.client_shares vector is permitted.

   Servers receiving a ClientHello which does not conform to these
   requirements MUST abort the handshake with a "missing_extension"
   alert.

Rescorla                 Expires January 4, 2018               [Page 96]
Internet-Draft                     TLS                         July 2017

   Additionally, all implementations MUST support use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.

10.  Security Considerations

   Security issues are discussed throughout this memo, especially in
   Appendix C, Appendix D, and Appendix E.

11.  IANA Considerations

   This document uses several registries that were originally created in
   [RFC4346].  IANA has updated these to reference this document.  The
   registries and their allocation policies are below:

   -  TLS Cipher Suite Registry: values with the first byte in the range
      0-254 (decimal) are assigned via Specification Required [RFC5226].
      Values with the first byte 255 (decimal) are reserved for Private
      Use [RFC5226].

      IANA [SHALL add/has added] the cipher suites listed in
      Appendix B.4 to the registry.  The "Value" and "Description"
      columns are taken from the table.  The "DTLS-OK" and "Recommended"
      columns are both marked as "Yes" for each new cipher suite.
      [[This assumes [I-D.ietf-tls-iana-registry-updates] has been
      applied.]]

   -  TLS ContentType Registry: Future values are allocated via
      Standards Action [RFC5226].

   -  TLS Alert Registry: Future values are allocated via Standards
      Action [RFC5226].  IANA [SHALL update/has updated] this registry
      to include values for "missing_extension" and
      "certificate_required".

   -  TLS HandshakeType Registry: Future values are allocated via
      Standards Action [RFC5226].  IANA [SHALL update/has updated] this
      registry to rename item 4 from "NewSessionTicket" to
      "new_session_ticket" and to add the "hello_retry_request",
      "encrypted_extensions", "end_of_early_data", "key_update", and
      "handshake_hash" values.

   This document also uses the TLS ExtensionType Registry originally
   created in [RFC4366].  IANA has updated it to reference this
   document.  The registry and its allocation policy is listed below:

Rescorla                 Expires January 4, 2018               [Page 97]
Internet-Draft                     TLS                         July 2017

   -  IANA [SHALL update/has updated] this registry to include the
      "key_share", "pre_shared_key", "psk_key_exchange_modes",
      "early_data", "cookie", "supported_versions",
      "certificate_authorities", "oid_filters", and
      "post_handshake_auth" extensions with the values defined in this
      document and the Recommended value of "Yes".

   -  IANA [SHALL update/has updated] this registry to include a "TLS
      1.3" column which lists the messages in which the extension may
      appear.  This column [SHALL be/has been] initially populated from
      the table in Section 4.2 with any extension not listed there
      marked as "-" to indicate that it is not used by TLS 1.3.

   In addition, this document defines a new registry to be maintained by
   IANA:

   -  TLS SignatureScheme Registry: Values with the first byte in the
      range 0-254 (decimal) are assigned via Specification Required
      [RFC5226].  Values with the first byte 255 (decimal) are reserved
      for Private Use [RFC5226].  Values with the first byte in the
      range 0-6 or with the second byte in the range 0-3 that are not
      currently allocated are reserved for backwards compatibility.
      This registry SHALL have a "Recommended" column.  The registry
      [shall be/ has been] initially populated with the values described
      in Section 4.2.3.  The following values SHALL be marked as
      "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
      rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.

12.  References

12.1.  Normative References

   [DH]       Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information Theory,
              V.IT-22 n.6 , June 1977.

   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC",
              NIST Special Publication 800-38D, November 2007.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <http://www.rfc-editor.org/info/rfc2104>.

Rescorla                 Expires January 4, 2018               [Page 98]
Internet-Draft                     TLS                         July 2017

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <http://www.rfc-editor.org/info/rfc5705>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655,
              DOI 10.17487/RFC6655, July 2012,
              <http://www.rfc-editor.org/info/rfc6655>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <http://www.rfc-editor.org/info/rfc6960>.

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,
              <http://www.rfc-editor.org/info/rfc6961>.

Rescorla                 Expires January 4, 2018               [Page 99]
Internet-Draft                     TLS                         July 2017

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
              2013, <http://www.rfc-editor.org/info/rfc6979>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <http://www.rfc-editor.org/info/rfc7301>.

   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
              <http://www.rfc-editor.org/info/rfc7507>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
              <http://www.rfc-editor.org/info/rfc7539>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <http://www.rfc-editor.org/info/rfc7748>.

   [RFC7919]  Gillmor, D., "Negotiated Finite Field Diffie-Hellman
              Ephemeral Parameters for Transport Layer Security (TLS)",
              RFC 7919, DOI 10.17487/RFC7919, August 2016,
              <http://www.rfc-editor.org/info/rfc7919>.

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <http://www.rfc-editor.org/info/rfc8017>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <http://www.rfc-editor.org/info/rfc8032>.

   [SHS]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Secure Hash Standard", NIST FIPS
              PUB 180-4, March 2012.

Rescorla                 Expires January 4, 2018              [Page 100]
Internet-Draft                     TLS                         July 2017

   [X690]     ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

   [X962]     ANSI, "Public Key Cryptography For The Financial Services
              Industry: The Elliptic Curve Digital Signature Algorithm
              (ECDSA)", ANSI X9.62, 1998.

12.2.  Informative References

   [AEAD-LIMITS]
              Luykx, A. and K. Paterson, "Limits on Authenticated
              Encryption Use in TLS", 2016,
              <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

   [BBFKZG16]
              Bhargavan, K., Brzuska, C., Fournet, C., Kohlweiss, M.,
              Zanella-Beguelin, S., and M. Green, "Downgrade Resilience
              in Key-Exchange Protocols", Proceedings of IEEE Symposium
              on Security and Privacy (Oakland) 2016 , 2016.

   [BBK17]    Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified
              Models and Reference Implementations for the TLS 1.3
              Standard Candidate", Proceedings of IEEE Symposium on
              Security and Privacy (Oakland) 2017 , 2017.

   [BDFKPPRSZZ16]
              Bhargavan, K., Delignat-Lavaud, A., Fournet, C.,
              Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy,
              N., Zanella-Beguelin, S., and J. Zinzindohoue,
              "Implementing and Proving the TLS 1.3 Record Layer",
              Proceedings of IEEE Symposium on Security and Privacy
              (Oakland) 2017 , December 2016,
              <https://eprint.iacr.org/2016/1178>.

   [BMMT15]   Badertscher, C., Matt, C., Maurer, U., and B. Tackmann,
              "Augmented Secure Channels and the Goal of the TLS 1.3
              Record Layer", ProvSec 2015 , September 2015,
              <https://eprint.iacr.org/2015/394>.

   [BT16]     Bellare, M. and B. Tackmann, "The Multi-User Security of
              Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings
              of CRYPTO 2016 , 2016, <https://eprint.iacr.org/2016/564>.

   [CCG16]    Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-
              Compromise Security", IEEE Computer Security Foundations
              Symposium , 2015.

Rescorla                 Expires January 4, 2018              [Page 101]
Internet-Draft                     TLS                         July 2017

   [CHHSV17]  Cremers, C., Horvat, M., Hoyland, J., van der Merwe, T.,
              and S. Scott, "Awkward Handshake: Possible mismatch of
              client/server view on client authentication in post-
              handshake mode in Revision 18", 2017,
              <https://www.ietf.org/mail-archive/web/tls/current/
              msg22382.html>.

   [CHSV16]   Cremers, C., Horvat, M., Scott, S., and T. van der Merwe,
              "Automated Analysis and Verification of TLS 1.3: 0-RTT,
              Resumption and Delayed Authentication", Proceedings of
              IEEE Symposium on Security and Privacy (Oakland) 2016 ,
              2016, <http://ieeexplore.ieee.org/document/7546518/>.

   [CK01]     Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
              Protocols and Their Use for Building Secure Channels",
              Proceedings of Eurocrypt 2001 , 2001.

   [CLINIC]   Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
              Why You Went to the Clinic: Risks and Realization of HTTPS
              Traffic Analysis", Privacy Enhancing Technologies pp.
              143-163, DOI 10.1007/978-3-319-08506-7_8, 2014.

   [DFGS15]   Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
              "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
              Pre-shared Key Handshake Protocol", Proceedings of ACM CCS
              2015 , 2015, <https://eprint.iacr.org/2015/914>.

   [DFGS16]   Dowling, B., Fischlin, M., Guenther, F., and D. Stebila,
              "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and
              Pre-shared Key Handshake Protocol", TRON 2016 , 2016,
              <https://eprint.iacr.org/2016/081>.

   [DOW92]    Diffie, W., van Oorschot, P., and M. Wiener,
              ""Authentication and authenticated key exchanges"",
              Designs, Codes and Cryptography , 1992.

   [DSS]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Digital Signature Standard,
              version 4", NIST FIPS PUB 186-4, 2013.

   [ECDSA]    American National Standards Institute, "Public Key
              Cryptography for the Financial Services Industry: The
              Elliptic Curve Digital Signature Algorithm (ECDSA)",
              ANSI ANS X9.62-2005, November 2005.

Rescorla                 Expires January 4, 2018              [Page 102]
Internet-Draft                     TLS                         July 2017

   [FG17]     Fischlin, M. and F. Guenther, "Replay Attacks on Zero
              Round-Trip Time: The Case of the TLS 1.3 Handshake
              Candidates", Proceedings of Euro S"P 2017 , 2017,
              <https://eprint.iacr.org/2017/082>.

   [FGSW16]   Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi,
              "Key Confirmation in Key Exchange: A Formal Treatment and
              Implications for TLS 1.3", Proceedings of IEEE Symposium
              on Security and Privacy (Oakland) 2016 , 2016,
              <http://ieeexplore.ieee.org/document/7546517/>.

   [FW15]     Florian Weimer, ., "Factoring RSA Keys With TLS Perfect
              Forward Secrecy", September 2015.

   [HCJ16]    Husak, M., &#268;ermak, M., Jirsik, T., and P.
              &#268;eleda, "HTTPS traffic analysis and client
              identification using passive SSL/TLS fingerprinting",
              EURASIP Journal on Information Security Vol. 2016,
              DOI 10.1186/s13635-016-0030-7, February 2016.

   [HGFS15]   Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes,
              "Prying Open Pandora's Box: KCI Attacks against TLS",
              Proceedings of USENIX Workshop on Offensive Technologies ,
              2015.

   [I-D.ietf-tls-iana-registry-updates]
              Salowey, J. and S. Turner, "D/TLS IANA Registry Updates",
              draft-ietf-tls-iana-registry-updates-01 (work in
              progress), April 2017.

   [I-D.ietf-tls-tls13-vectors]
              Thomson, M., "Example Handshake Traces for TLS 1.3",
              draft-ietf-tls-tls13-vectors-01 (work in progress), June
              2017.

   [IEEE1363]
              IEEE, "Standard Specifications for Public Key
              Cryptography", IEEE 1363 , 2000.

   [KEYAGREEMENT]
              Barker, E., Lily Chen, ., Roginsky, A., and M. Smid,
              "Recommendation for Pair-Wise Key Establishment Schemes
              Using Discrete Logarithm Cryptography", NIST Special
              Publication 800-38D, May 2013.

   [Kraw10]   Krawczyk, H., "Cryptographic Extraction and Key
              Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 ,
              2010, <https://eprint.iacr.org/2010/264>.

Rescorla                 Expires January 4, 2018              [Page 103]
Internet-Draft                     TLS                         July 2017

   [Kraw16]   Krawczyk, H., "A Unilateral-to-Mutual Authentication
              Compiler for Key Exchange (with Applications to Client
              Authentication in TLS 1.3", Proceedings of ACM CCS 2016 ,
              2016, <https://eprint.iacr.org/2016/711>.

   [KW16]     Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3",
              Proceedings of Euro S"P 2016 , 2016,
              <https://eprint.iacr.org/2015/978>.

   [LXZFH16]  Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple
              Handshakes Security of TLS 1.3 Candidates", Proceedings of
              IEEE Symposium on Security and Privacy (Oakland) 2016 ,
              2016, <http://ieeexplore.ieee.org/document/7546519/>.

   [Mac17]    MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", 2017,
              <https://github.com/tlswg/tls13-spec/issues/1001>.

   [PSK-FINISHED]
              Cremers, C., Horvat, M., van der Merwe, T., and S. Scott,
              "Revision 10: possible attack if client authentication is
              allowed during PSK", 2015, <https://www.ietf.org/mail-
              archive/web/tls/current/msg18215.html>.

   [REKEY]    Abdalla, M. and M. Bellare, "Increasing the Lifetime of a
              Key: A Comparative Analysis of the Security of Re-keying
              Techniques", ASIACRYPT2000 , October 2000.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <http://www.rfc-editor.org/info/rfc3552>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <http://www.rfc-editor.org/info/rfc4086>.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346,
              DOI 10.17487/RFC4346, April 2006,
              <http://www.rfc-editor.org/info/rfc4346>.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
              <http://www.rfc-editor.org/info/rfc4366>.

Rescorla                 Expires January 4, 2018              [Page 104]
Internet-Draft                     TLS                         July 2017

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492,
              DOI 10.17487/RFC4492, May 2006,
              <http://www.rfc-editor.org/info/rfc4492>.

   [RFC4681]  Santesson, S., Medvinsky, A., and J. Ball, "TLS User
              Mapping Extension", RFC 4681, DOI 10.17487/RFC4681,
              October 2006, <http://www.rfc-editor.org/info/rfc4681>.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <http://www.rfc-editor.org/info/rfc5077>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <http://www.rfc-editor.org/info/rfc5116>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764,
              DOI 10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
              <http://www.rfc-editor.org/info/rfc5929>.

   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
              for Transport Layer Security (TLS) Authentication",
              RFC 6091, DOI 10.17487/RFC6091, February 2011,
              <http://www.rfc-editor.org/info/rfc6091>.

   [RFC6176]  Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
              (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March
              2011, <http://www.rfc-editor.org/info/rfc6176>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

Rescorla                 Expires January 4, 2018              [Page 105]
Internet-Draft                     TLS                         July 2017

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520,
              DOI 10.17487/RFC6520, February 2012,
              <http://www.rfc-editor.org/info/rfc6520>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,
              <http://www.rfc-editor.org/info/rfc7465>.

   [RFC7568]  Barnes, R., Thomson, M., Pironti, A., and A. Langley,
              "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
              DOI 10.17487/RFC7568, June 2015,
              <http://www.rfc-editor.org/info/rfc7568>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <http://www.rfc-editor.org/info/rfc7627>.

   [RFC7685]  Langley, A., "A Transport Layer Security (TLS) ClientHello
              Padding Extension", RFC 7685, DOI 10.17487/RFC7685,
              October 2015, <http://www.rfc-editor.org/info/rfc7685>.

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016,
              <http://www.rfc-editor.org/info/rfc7924>.

   [RSA]      Rivest, R., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
              120-126., February 1978.

Rescorla                 Expires January 4, 2018              [Page 106]
Internet-Draft                     TLS                         July 2017

   [SIGMA]    Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' approach to
              authenticated Diffie-Hellman and its use in the IKE
              protocols", Proceedings of CRYPTO 2003 , 2003.

   [SLOTH]    Bhargavan, K. and G. Leurent, "Transcript Collision
              Attacks: Breaking Authentication in TLS, IKE, and SSH",
              Network and Distributed System Security Symposium (NDSS
              2016) , 2016.

   [SSL2]     Hickman, K., "The SSL Protocol", February 1995.

   [SSL3]     Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0
              Protocol", November 1996.

   [TIMING]   Boneh, D. and D. Brumley, "Remote timing attacks are
              practical", USENIX Security Symposium, 2003.

   [X501]     "Information Technology - Open Systems Interconnection -
              The Directory: Models", ITU-T X.501, 1993.

12.3.  URIs

   [1] mailto:tls@ietf.org

Rescorla                 Expires January 4, 2018              [Page 107]
Internet-Draft                     TLS                         July 2017

Appendix A.  State Machine

   This section provides a summary of the legal state transitions for
   the client and server handshakes.  State names (in all capitals,
   e.g., START) have no formal meaning but are provided for ease of
   comprehension.  Actions which are taken only in certain circumstances
   are indicated in [].  The notation "K_{send,recv} = foo" means "set
   the send/recv key to the given key".

A.1.  Client

                              START <----+
               Send ClientHello |        | Recv HelloRetryRequest
          [K_send = early data] |        |
                                v        |
           /                 WAIT_SH ----+
           |                    | Recv ServerHello
           |                    | K_recv = handshake
       Can |                    V
      send |                 WAIT_EE
     early |                    | Recv EncryptedExtensions
      data |           +--------+--------+
           |     Using |                 | Using certificate
           |       PSK |                 v
           |           |            WAIT_CERT_CR
           |           |        Recv |       | Recv CertificateRequest
           |           | Certificate |       v
           |           |             |    WAIT_CERT
           |           |             |       | Recv Certificate
           |           |             v       v
           |           |              WAIT_CV
           |           |                 | Recv CertificateVerify
           |           +> WAIT_FINISHED <+
           |                  | Recv Finished
           \                  | [Send EndOfEarlyData]
                              | K_send = handshake
                              | [Send Certificate [+ CertificateVerify]]
    Can send                  | Send Finished
    app data   -->            | K_send = K_recv = application
    after here                v
                          CONNECTED

   Note that with the transitions as shown above, clients may send
   alerts that derive from post-ServerHello messages in the clear or
   with the early data keys.  If clients need to send such alerts, they
   SHOULD first rekey to the handshake keys if possible.

Rescorla                 Expires January 4, 2018              [Page 108]
Internet-Draft                     TLS                         July 2017

A.2.  Server

                              START <-----+
               Recv ClientHello |         | Send HelloRetryRequest
                                v         |
                             RECVD_CH ----+
                                | Select parameters
                                v
                             NEGOTIATED
                                | Send ServerHello
                                | K_send = handshake
                                | Send EncryptedExtensions
                                | [Send CertificateRequest]
 Can send                       | [Send Certificate + CertificateVerify]
 app data                       | Send Finished
 after   -->                    | K_send = application
 here                  +--------+--------+
              No 0-RTT |                 | 0-RTT
    K_recv = handshake |                 | K_recv = early_data
 [Skip decrypt errors] |             WAIT_EOED <---+
                       |            Recv |   |     | Recv
                       |  EndOfEarlyData |   |     | Early data
                       |        K_recv = |   +-----+
                       |       handshake |
                       |                 |
                       +> WAIT_FLIGHT2 <-+
                                |
                       +--------+--------+
               No auth |                 | Client auth
                       |                 |
                       |                 v
                       |             WAIT_CERT
                       |        Recv |       | Recv Certificate
                       |       empty |       v
                       | Certificate |    WAIT_CV
                       |             |       | Recv
                       |             v       | CertificateVerify
                       +-> WAIT_FINISHED <---+
                                | Recv Finished
                                | K_recv = application
                                v
                            CONNECTED

Appendix B.  Protocol Data Structures and Constant Values

   This section describes protocol types and constants.  Values listed
   as _RESERVED were used in previous versions of TLS and are listed

Rescorla                 Expires January 4, 2018              [Page 109]
Internet-Draft                     TLS                         July 2017

   here for completeness.  TLS 1.3 implementations MUST NOT send them
   but might receive them from older TLS implementations.

B.1.  Record Layer

      enum {
          invalid(0),
          change_cipher_spec_RESERVED(20),
          alert(21),
          handshake(22),
          application_data(23),
          (255)
      } ContentType;

      struct {
          ContentType type;
          ProtocolVersion legacy_record_version;
          uint16 length;
          opaque fragment[TLSPlaintext.length];
      } TLSPlaintext;

      struct {
          opaque content[TLSPlaintext.length];
          ContentType type;
          uint8 zeros[length_of_padding];
      } TLSInnerPlaintext;

      struct {
          ContentType opaque_type = 23; /* application_data */
          ProtocolVersion legacy_record_version = 0x0301; /* TLS v1.x */
          uint16 length;
          opaque encrypted_record[length];
      } TLSCiphertext;

B.2.  Alert Messages

Rescorla                 Expires January 4, 2018              [Page 110]
Internet-Draft                     TLS                         July 2017

      enum { warning(1), fatal(2), (255) } AlertLevel;

      enum {
          close_notify(0),
          unexpected_message(10),
          bad_record_mac(20),
          decryption_failed_RESERVED(21),
          record_overflow(22),
          decompression_failure_RESERVED(30),
          handshake_failure(40),
          no_certificate_RESERVED(41),
          bad_certificate(42),
          unsupported_certificate(43),
          certificate_revoked(44),
          certificate_expired(45),
          certificate_unknown(46),
          illegal_parameter(47),
          unknown_ca(48),
          access_denied(49),
          decode_error(50),
          decrypt_error(51),
          export_restriction_RESERVED(60),
          protocol_version(70),
          insufficient_security(71),
          internal_error(80),
          inappropriate_fallback(86),
          user_canceled(90),
          no_renegotiation_RESERVED(100),
          missing_extension(109),
          unsupported_extension(110),
          certificate_unobtainable(111),
          unrecognized_name(112),
          bad_certificate_status_response(113),
          bad_certificate_hash_value(114),
          unknown_psk_identity(115),
          certificate_required(116),
          no_application_protocol(120),
          (255)
      } AlertDescription;

      struct {
          AlertLevel level;
          AlertDescription description;
      } Alert;

Rescorla                 Expires January 4, 2018              [Page 111]
Internet-Draft                     TLS                         July 2017

B.3.  Handshake Protocol

      enum {
          hello_request_RESERVED(0),
          client_hello(1),
          server_hello(2),
          hello_verify_request_RESERVED(3),
          new_session_ticket(4),
          end_of_early_data(5),
          hello_retry_request(6),
          encrypted_extensions(8),
          certificate(11),
          server_key_exchange_RESERVED(12),
          certificate_request(13),
          server_hello_done_RESERVED(14),
          certificate_verify(15),
          client_key_exchange_RESERVED(16),
          finished(20),
          key_update(24),
          message_hash(254),
          (255)
      } HandshakeType;

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case hello_retry_request:   HelloRetryRequest;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
          } body;
      } Handshake;

B.3.1.  Key Exchange Messages

   uint16 ProtocolVersion;
   opaque Random[32];

   uint8 CipherSuite[2];    /* Cryptographic suite selector */

Rescorla                 Expires January 4, 2018              [Page 112]
Internet-Draft                     TLS                         July 2017

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id<0..32>;
       CipherSuite cipher_suites<2..2^16-2>;
       opaque legacy_compression_methods<1..2^8-1>;
       Extension extensions<8..2^16-1>;
   } ClientHello;

   struct {
       ProtocolVersion version;
       Random random;
       CipherSuite cipher_suite;
       Extension extensions<6..2^16-1>;
   } ServerHello;

   struct {
       ProtocolVersion server_version;
       CipherSuite cipher_suite;
       Extension extensions<2..2^16-1>;
   } HelloRetryRequest;

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

   enum {
       server_name(0),                             /* RFC 6066 */
       max_fragment_length(1),                     /* RFC 6066 */
       status_request(5),                          /* RFC 6066 */
       supported_groups(10),                       /* RFC 4492, 7919 */
       signature_algorithms(13),                   /* RFC 5246 */
       use_srtp(14),                               /* RFC 5764 */
       heartbeat(15),                              /* RFC 6520 */
       application_layer_protocol_negotiation(16), /* RFC 7301 */
       signed_certificate_timestamp(18),           /* RFC 6962 */
       client_certificate_type(19),                /* RFC 7250 */
       server_certificate_type(20),                /* RFC 7250 */
       padding(21),                                /* RFC 7685 */
       key_share(40),                              /* [[this document]] */
       pre_shared_key(41),                         /* [[this document]] */
       early_data(42),                             /* [[this document]] */
       supported_versions(43),                     /* [[this document]] */
       cookie(44),                                 /* [[this document]] */
       psk_key_exchange_modes(45),                 /* [[this document]] */
       certificate_authorities(47),                /* [[this document]] */
       oid_filters(48),                            /* [[this document]] */

Rescorla                 Expires January 4, 2018              [Page 113]
Internet-Draft                     TLS                         July 2017

       post_handshake_auth(49),                    /* [[this document]] */
       (65535)
   } ExtensionType;

   struct {
       NamedGroup group;
       opaque key_exchange<1..2^16-1>;
   } KeyShareEntry;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               KeyShareEntry client_shares<0..2^16-1>;

           case hello_retry_request:
               NamedGroup selected_group;

           case server_hello:
               KeyShareEntry server_share;
       };
   } KeyShare;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;

   struct {
       PskKeyExchangeMode ke_modes<1..255>;
   } PskKeyExchangeModes;

   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

   struct {
       select (Handshake.msg_type) {
           case client_hello:

Rescorla                 Expires January 4, 2018              [Page 114]
Internet-Draft                     TLS                         July 2017

               PskIdentity identities<7..2^16-1>;
               PskBinderEntry binders<33..2^16-1>;

           case server_hello:
               uint16 selected_identity;
       };

   } PreSharedKeyExtension;

B.3.1.1.  Version Extension

      struct {
          ProtocolVersion versions<2..254>;
      } SupportedVersions;

B.3.1.2.  Cookie Extension

      struct {
          opaque cookie<1..2^16-1>;
      } Cookie;

B.3.1.3.  Signature Algorithm Extension

Rescorla                 Expires January 4, 2018              [Page 115]
Internet-Draft                     TLS                         July 2017

      enum {
          /* RSASSA-PKCS1-v1_5 algorithms */
          rsa_pkcs1_sha256(0x0401),
          rsa_pkcs1_sha384(0x0501),
          rsa_pkcs1_sha512(0x0601),

          /* ECDSA algorithms */
          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

          /* RSASSA-PSS algorithms */
          rsa_pss_sha256(0x0804),
          rsa_pss_sha384(0x0805),
          rsa_pss_sha512(0x0806),

          /* EdDSA algorithms */
          ed25519(0x0807),
          ed448(0x0808),

          /* Legacy algorithms */
          rsa_pkcs1_sha1(0x0201),
          ecdsa_sha1(0x0203),

          /* Reserved Code Points */
          obsolete_RESERVED(0x0000..0x0200),
          dsa_sha1_RESERVED(0x0202),
          obsolete_RESERVED(0x0204..0x0400),
          dsa_sha256_RESERVED(0x0402),
          obsolete_RESERVED(0x0404..0x0500),
          dsa_sha384_RESERVED(0x0502),
          obsolete_RESERVED(0x0504..0x0600),
          dsa_sha512_RESERVED(0x0602),
          obsolete_RESERVED(0x0604..0x06FF),
          private_use(0xFE00..0xFFFF),
          (0xFFFF)
      } SignatureScheme;

      struct {
          SignatureScheme supported_signature_algorithms<2..2^16-2>;
      } SignatureSchemeList;

B.3.1.4.  Supported Groups Extension

Rescorla                 Expires January 4, 2018              [Page 116]
Internet-Draft                     TLS                         July 2017

      enum {
          /* Elliptic Curve Groups (ECDHE) */
          obsolete_RESERVED(0x0001..0x0016),
          secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
          obsolete_RESERVED(0x001A..0x001C),
          x25519(0x001D), x448(0x001E),

          /* Finite Field Groups (DHE) */
          ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096 (0x0102),
          ffdhe6144(0x0103), ffdhe8192(0x0104),

          /* Reserved Code Points */
          ffdhe_private_use(0x01FC..0x01FF),
          ecdhe_private_use(0xFE00..0xFEFF),
          obsolete_RESERVED(0xFF01..0xFF02),
          (0xFFFF)
      } NamedGroup;

      struct {
          NamedGroup named_group_list<2..2^16-1>;
      } NamedGroupList;

   Values within "obsolete_RESERVED" ranges are used in previous
   versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
   implementations.  The obsolete curves have various known/theoretical
   weaknesses or have had very little usage, in some cases only due to
   unintentional server configuration issues.  They are no longer
   considered appropriate for general use and should be assumed to be
   potentially unsafe.  The set of curves specified here is sufficient
   for interoperability with all currently deployed and properly
   configured TLS implementations.

B.3.2.  Server Parameters Messages

Rescorla                 Expires January 4, 2018              [Page 117]
Internet-Draft                     TLS                         July 2017

      opaque DistinguishedName<1..2^16-1>;

      struct {
          DistinguishedName authorities<3..2^16-1>;
      } CertificateAuthoritiesExtension;

      struct {
          opaque certificate_extension_oid<1..2^8-1>;
          opaque certificate_extension_values<0..2^16-1>;
      } OIDFilter;

      struct {
          OIDFilter filters<0..2^16-1>;
      } OIDFilterExtension;

      struct {
          Extension extensions<0..2^16-1>;
      } EncryptedExtensions;

      struct {
          opaque certificate_request_context<0..2^8-1>;
          Extension extensions<2..2^16-1>;
      } CertificateRequest;

B.3.3.  Authentication Messages

Rescorla                 Expires January 4, 2018              [Page 118]
Internet-Draft                     TLS                         July 2017

      struct {
          select(certificate_type){
              case RawPublicKey:
                // From RFC 7250 ASN.1_subjectPublicKeyInfo
                opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

              case X509:
                opaque cert_data<1..2^24-1>;
          };
          Extension extensions<0..2^16-1>;
      } CertificateEntry;

      struct {
          opaque certificate_request_context<0..2^8-1>;
          CertificateEntry certificate_list<0..2^24-1>;
      } Certificate;

      struct {
          SignatureScheme algorithm;
          opaque signature<0..2^16-1>;
      } CertificateVerify;

      struct {
          opaque verify_data[Hash.length];
      } Finished;

B.3.4.  Ticket Establishment

      struct {
          uint32 ticket_lifetime;
          uint32 ticket_age_add;
          opaque ticket_nonce<1..255>;
          opaque ticket<1..2^16-1>;
          Extension extensions<0..2^16-2>;
      } NewSessionTicket;

B.3.5.  Updating Keys

      struct {} EndOfEarlyData;

      enum {
          update_not_requested(0), update_requested(1), (255)
      } KeyUpdateRequest;

      struct {
          KeyUpdateRequest request_update;
      } KeyUpdate;

Rescorla                 Expires January 4, 2018              [Page 119]
Internet-Draft                     TLS                         July 2017

B.4.  Cipher Suites

   A symmetric cipher suite defines the pair of the AEAD algorithm and
   hash algorithm to be used with HKDF.  Cipher suite names follow the
   naming convention:

      CipherSuite TLS_AEAD_HASH = VALUE;

      +-----------+------------------------------------------------+
      | Component | Contents                                       |
      +-----------+------------------------------------------------+
      | TLS       | The string "TLS"                               |
      |           |                                                |
      | AEAD      | The AEAD algorithm used for record protection  |
      |           |                                                |
      | HASH      | The hash algorithm used with HKDF              |
      |           |                                                |
      | VALUE     | The two byte ID assigned for this cipher suite |
      +-----------+------------------------------------------------+

   This specification defines the following cipher suites for use with
   TLS 1.3.

              +------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

   The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM,
   and AEAD_AES_128_CCM are defined in [RFC5116].
   AEAD_CHACHA20_POLY1305 is defined in [RFC7539].  AEAD_AES_128_CCM_8
   is defined in [RFC6655].  The corresponding hash algorithms are
   defined in [SHS].

   Although TLS 1.3 uses the same cipher suite space as previous
   versions of TLS, TLS 1.3 cipher suites are defined differently, only
   specifying the symmetric ciphers, and cannot be used for TLS 1.2.
   Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS
   1.3.

Rescorla                 Expires January 4, 2018              [Page 120]
Internet-Draft                     TLS                         July 2017

   New cipher suite values are assigned by IANA as described in
   Section 11.

Appendix C.  Implementation Notes

   The TLS protocol cannot prevent many common security mistakes.  This
   section provides several recommendations to assist implementors.
   [I-D.ietf-tls-tls13-vectors] provides test vectors for TLS 1.3
   handshakes.

C.1.  Random Number Generation and Seeding

   TLS requires a cryptographically secure pseudorandom number generator
   (CSPRNG).  In most cases, the operating system provides an
   appropriate facility such as /dev/urandom, which should be used
   absent other (performance) concerns.  It is RECOMMENDED to use an
   existing CSPRNG implementation in preference to crafting a new one.
   Many adequate cryptographic libraries are already available under
   favorable license terms.  Should those prove unsatisfactory,
   [RFC4086] provides guidance on the generation of random values.

C.2.  Certificates and Authentication

   Implementations are responsible for verifying the integrity of
   certificates and should generally support certificate revocation
   messages.  Absent a specific indication from an application profile,
   Certificates should always be verified to ensure proper signing by a
   trusted Certificate Authority (CA).  The selection and addition of
   trust anchors should be done very carefully.  Users should be able to
   view information about the certificate and trust anchor.
   Applications SHOULD also enforce minimum and maximum key sizes.  For
   example, certification paths containing keys or signatures weaker
   than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure
   applications.

C.3.  Implementation Pitfalls

   Implementation experience has shown that certain parts of earlier TLS
   specifications are not easy to understand and have been a source of
   interoperability and security problems.  Many of these areas have
   been clarified in this document but this appendix contains a short
   list of the most important things that require special attention from
   implementors.

   TLS protocol issues:

   -  Do you correctly handle handshake messages that are fragmented to
      multiple TLS records (see Section 5.1)?  Including corner cases

Rescorla                 Expires January 4, 2018              [Page 121]
Internet-Draft                     TLS                         July 2017

      like a ClientHello that is split to several small fragments?  Do
      you fragment handshake messages that exceed the maximum fragment
      size?  In particular, the Certificate and CertificateRequest
      handshake messages can be large enough to require fragmentation.

   -  Do you ignore the TLS record layer version number in all
      unencrypted TLS records? (see Appendix D)

   -  Have you ensured that all support for SSL, RC4, EXPORT ciphers,
      and MD5 (via the "signature_algorithms" extension) is completely
      removed from all possible configurations that support TLS 1.3 or
      later, and that attempts to use these obsolete capabilities fail
      correctly? (see Appendix D)

   -  Do you handle TLS extensions in ClientHello correctly, including
      unknown extensions?

   -  When the server has requested a client certificate, but no
      suitable certificate is available, do you correctly send an empty
      Certificate message, instead of omitting the whole message (see
      Section 4.4.2.3)?

   -  When processing the plaintext fragment produced by AEAD-Decrypt
      and scanning from the end for the ContentType, do you avoid
      scanning past the start of the cleartext in the event that the
      peer has sent a malformed plaintext of all-zeros?

   -  Do you properly ignore unrecognized cipher suites (Section 4.1.2),
      hello extensions (Section 4.2), named groups (Section 4.2.6), key
      shares Section 4.2.7, supported versions Section 4.2.1, and
      signature algorithms (Section 4.2.3) in the ClientHello?

   -  As a server, do you send a HelloRetryRequest to clients which
      support a compatible (EC)DHE group but do not predict it in the
      "key_share" extension?  As a client, do you correctly handle a
      HelloRetryRequest from the server?

   Cryptographic details:

   -  What countermeasures do you use to prevent timing attacks
      [TIMING]?

   -  When using Diffie-Hellman key exchange, do you correctly preserve
      leading zero bytes in the negotiated key (see Section 7.4.1)?

   -  Does your TLS client check that the Diffie-Hellman parameters sent
      by the server are acceptable, (see Section 4.2.7.1)?

Rescorla                 Expires January 4, 2018              [Page 122]
Internet-Draft                     TLS                         July 2017

   -  Do you use a strong and, most importantly, properly seeded random
      number generator (see Appendix C.1) when generating Diffie-Hellman
      private values, the ECDSA "k" parameter, and other security-
      critical values?  It is RECOMMENDED that implementations implement
      "deterministic ECDSA" as specified in [RFC6979].

   -  Do you zero-pad Diffie-Hellman public key values to the group size
      (see Section 4.2.7.1)?

   -  Do you verify signatures after making them to protect against RSA-
      CRT key leaks?  [FW15]

C.4.  Client Tracking Prevention

   Clients SHOULD NOT reuse a ticket for multiple connections.  Reuse of
   a ticket allows passive observers to correlate different connections.
   Servers that issue tickets SHOULD offer at least as many tickets as
   the number of connections that a client might use; for example, a web
   browser using HTTP/1.1 [RFC7230] might open six connections to a
   server.  Servers SHOULD issue new tickets with every connection.
   This ensures that clients are always able to use a new ticket when
   creating a new connection.

C.5.  Unauthenticated Operation

   Previous versions of TLS offered explicitly unauthenticated cipher
   suites based on anonymous Diffie-Hellman.  These modes have been
   deprecated in TLS 1.3.  However, it is still possible to negotiate
   parameters that do not provide verifiable server authentication by
   several methods, including:

   -  Raw public keys [RFC7250].

   -  Using a public key contained in a certificate but without
      validation of the certificate chain or any of its contents.

   Either technique used alone is vulnerable to man-in-the-middle
   attacks and therefore unsafe for general use.  However, it is also
   possible to bind such connections to an external authentication
   mechanism via out-of-band validation of the server's public key,
   trust on first use, or a mechanism such as channel bindings (though
   the channel bindings described in [RFC5929] are not defined for TLS
   1.3).  If no such mechanism is used, then the connection has no
   protection against active man-in-the-middle attack; applications MUST
   NOT use TLS in such a way absent explicit configuration or a specific
   application profile.

Rescorla                 Expires January 4, 2018              [Page 123]
Internet-Draft                     TLS                         July 2017

Appendix D.  Backward Compatibility

   The TLS protocol provides a built-in mechanism for version
   negotiation between endpoints potentially supporting different
   versions of TLS.

   TLS 1.x and SSL 3.0 use compatible ClientHello messages.  Servers can
   also handle clients trying to use future versions of TLS as long as
   the ClientHello format remains compatible and the client supports the
   highest protocol version available in the server.

   Prior versions of TLS used the record layer version number for
   various purposes.  (TLSPlaintext.legacy_record_version and
   TLSCiphertext.legacy_record_version) As of TLS 1.3, this field is
   deprecated.  The value of TLSPlaintext.legacy_record_version MUST be
   ignored by all implementations.  The value of
   TLSCiphertext.legacy_record_version MAY be ignored, or MAY be
   validated to match the fixed constant value.  Version negotiation is
   performed using only the handshake versions
   (ClientHello.legacy_version, ClientHello "supported_versions"
   extension, and ServerHello.version).  In order to maximize
   interoperability with older endpoints, implementations that negotiate
   the use of TLS 1.0-1.2 SHOULD set the record layer version number to
   the negotiated version for the ServerHello and all records
   thereafter.

   For maximum compatibility with previously non-standard behavior and
   misconfigured deployments, all implementations SHOULD support
   validation of certification paths based on the expectations in this
   document, even when handling prior TLS versions' handshakes. (see
   Section 4.4.2.2)

   TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627]
   extension which digested large parts of the handshake transcript into
   the master secret.  Because TLS 1.3 always hashes in the transcript
   up to the server CertificateVerify, implementations which support
   both TLS 1.3 and earlier versions SHOULD indicate the use of the
   Extended Master Secret extension in their APIs whenever TLS 1.3 is
   used.

D.1.  Negotiating with an older server

   A TLS 1.3 client who wishes to negotiate with servers that do not
   support TLS 1.3 will send a normal TLS 1.3 ClientHello containing
   0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct
   version in the "supported_versions" extension.  If the server does
   not support TLS 1.3 it will respond with a ServerHello containing an
   older version number.  If the client agrees to use this version, the

Rescorla                 Expires January 4, 2018              [Page 124]
Internet-Draft                     TLS                         July 2017

   negotiation will proceed as appropriate for the negotiated protocol.
   A client using a ticket for resumption SHOULD initiate the connection
   using the version that was previously negotiated.

   Note that 0-RTT data is not compatible with older servers and SHOULD
   NOT be sent absent knowledge that the server supports TLS 1.3.  See
   Appendix D.3.

   If the version chosen by the server is not supported by the client
   (or not acceptable), the client MUST abort the handshake with a
   "protocol_version" alert.

   Some legacy server implementations are known to not implement the TLS
   specification properly and might abort connections upon encountering
   TLS extensions or versions which they are not aware of.
   Interoperability with buggy servers is a complex topic beyond the
   scope of this document.  Multiple connection attempts may be required
   in order to negotiate a backwards compatible connection; however,
   this practice is vulnerable to downgrade attacks and is NOT
   RECOMMENDED.

D.2.  Negotiating with an older client

   A TLS server can also receive a ClientHello indicating a version
   number smaller than its highest supported version.  If the
   "supported_versions" extension is present, the server MUST negotiate
   using that extension as described in Section 4.2.1.  If the
   "supported_versions" extension is not present, the server MUST
   negotiate the minimum of ClientHello.legacy_version and TLS 1.2.  For
   example, if the server supports TLS 1.0, 1.1, and 1.2, and
   legacy_version is TLS 1.0, the server will proceed with a TLS 1.0
   ServerHello.  If the "supported_versions" extension is absent and the
   server only supports versions greater than
   ClientHello.legacy_version, the server MUST abort the handshake with
   a "protocol_version" alert.

   Note that earlier versions of TLS did not clearly specify the record
   layer version number value in all cases
   (TLSPlaintext.legacy_record_version).  Servers will receive various
   TLS 1.x versions in this field, but its value MUST always be ignored.

D.3.  Zero-RTT backwards compatibility

   0-RTT data is not compatible with older servers.  An older server
   will respond to the ClientHello with an older ServerHello, but it
   will not correctly skip the 0-RTT data and will fail to complete the
   handshake.  This can cause issues when a client attempts to use
   0-RTT, particularly against multi-server deployments.  For example, a

Rescorla                 Expires January 4, 2018              [Page 125]
Internet-Draft                     TLS                         July 2017

   deployment could deploy TLS 1.3 gradually with some servers
   implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3
   deployment could be downgraded to TLS 1.2.

   A client that attempts to send 0-RTT data MUST fail a connection if
   it receives a ServerHello with TLS 1.2 or older.  A client that
   attempts to repair this error SHOULD NOT send a TLS 1.2 ClientHello,
   but instead send a TLS 1.3 ClientHello without 0-RTT data.

   To avoid this error condition, multi-server deployments SHOULD ensure
   a uniform and stable deployment of TLS 1.3 without 0-RTT prior to
   enabling 0-RTT.

D.4.  Backwards Compatibility Security Restrictions

   Implementations negotiating use of older versions of TLS SHOULD
   prefer forward secret and AEAD cipher suites, when available.

   The security of RC4 cipher suites is considered insufficient for the
   reasons cited in [RFC7465].  Implementations MUST NOT offer or
   negotiate RC4 cipher suites for any version of TLS for any reason.

   Old versions of TLS permitted the use of very low strength ciphers.
   Ciphers with a strength less than 112 bits MUST NOT be offered or
   negotiated for any version of TLS for any reason.

   The security of SSL 3.0 [SSL3] is considered insufficient for the
   reasons enumerated in [RFC7568], and MUST NOT be negotiated for any
   reason.

   The security of SSL 2.0 [SSL2] is considered insufficient for the
   reasons enumerated in [RFC6176], and MUST NOT be negotiated for any
   reason.

   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
   HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
   SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
   RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
   order to negotiate older versions of TLS.

   Implementations MUST NOT send a ClientHello.legacy_version or
   ServerHello.version set to 0x0300 or less.  Any endpoint receiving a
   Hello message with ClientHello.legacy_version or ServerHello.version
   set to 0x0300 MUST abort the handshake with a "protocol_version"
   alert.

   Implementations MUST NOT send any records with a version less than
   0x0300.  Implementations SHOULD NOT accept any records with a version

Rescorla                 Expires January 4, 2018              [Page 126]
Internet-Draft                     TLS                         July 2017

   less than 0x0300 (but may inadvertently do so if the record version
   number is ignored completely).

   Implementations MUST NOT use the Truncated HMAC extension, defined in
   Section 7 of [RFC6066], as it is not applicable to AEAD algorithms
   and has been shown to be insecure in some scenarios.

Appendix E.  Overview of Security Properties

   A complete security analysis of TLS is outside the scope of this
   document.  In this section, we provide an informal description the
   desired properties as well as references to more detailed work in the
   research literature which provides more formal definitions.

   We cover properties of the handshake separately from those of the
   record layer.

E.1.  Handshake

   The TLS handshake is an Authenticated Key Exchange (AKE) protocol
   which is intended to provide both one-way authenticated (server-only)
   and mutually authenticated (client and server) functionality.  At the
   completion of the handshake, each side outputs its view of the
   following values:

   -  A set of "session keys" (the various secrets derived from the
      master secret) from which can be derived a set of working keys.

   -  A set of cryptographic parameters (algorithms, etc.)

   -  The identities of the communicating parties.

   We assume the attacker to be an active network attacker, which means
   it has complete control over the network used to communicate between
   the parties [RFC3552].  Even under these conditions, the handshake
   should provide the properties listed below.  Note that these
   properties are not necessarily independent, but reflect the protocol
   consumers' needs.

   Establishing the same session keys.  The handshake needs to output
      the same set of session keys on both sides of the handshake,
      provided that it completes successfully on each endpoint (See
      [CK01]; defn 1, part 1).

   Secrecy of the session keys.  The shared session keys should be known
      only to the communicating parties and not to the attacker (See
      [CK01]; defn 1, part 2).  Note that in a unilaterally
      authenticated connection, the attacker can establish its own

Rescorla                 Expires January 4, 2018              [Page 127]
Internet-Draft                     TLS                         July 2017

      session keys with the server, but those session keys are distinct
      from those established by the client.

   Peer Authentication.  The client's view of the peer identity should
      reflect the server's identity.  If the client is authenticated,
      the server's view of the peer identity should match the client's
      identity.

   Uniqueness of the session keys:  Any two distinct handshakes should
      produce distinct, unrelated session keys.  Individual session keys
      produced by a handshake should also be distinct and unrelated.

   Downgrade protection.  The cryptographic parameters should be the
      same on both sides and should be the same as if the peers had been
      communicating in the absence of an attack (See [BBFKZG16]; defns 8
      and 9}).

   Forward secret with respect to long-term keys  If the long-term
      keying material (in this case the signature keys in certificate-
      based authentication modes or the external/resumption PSK in PSK
      with (EC)DHE modes) is compromised after the handshake is
      complete, this does not compromise the security of the session key
      (See [DOW92]), as long as the session key itself has been erased.
      The forward secrecy property is not satisfied when PSK is used in
      the "psk_ke" PskKeyExchangeMode.

   Key Compromise Impersonation (KCI) resistance  In a mutually-
      authenticated connection with certificates, peer authentication
      should hold even if the local long-term secret was compromised
      before the connection was established (see [HGFS15]).  For
      example, if a client's signature key is compromised, it should not
      be possible to impersonate arbitrary servers to that client in
      subsequent handshakes.

   Protection of endpoint identities.  The server's identity
      (certificate) should be protected against passive attackers.  The
      client's identity should be protected against both passive and
      active attackers.

   Informally, the signature-based modes of TLS 1.3 provide for the
   establishment of a unique, secret, shared key established by an
   (EC)DHE key exchange and authenticated by the server's signature over
   the handshake transcript, as well as tied to the server's identity by
   a MAC.  If the client is authenticated by a certificate, it also
   signs over the handshake transcript and provides a MAC tied to both
   identities.  [SIGMA] describes the design and analysis of this type
   of key exchange protocol.  If fresh (EC)DHE keys are used for each
   connection, then the output keys are forward secret.

Rescorla                 Expires January 4, 2018              [Page 128]
Internet-Draft                     TLS                         July 2017

   The external PSK and resumption PSK bootstrap from a long-term shared
   secret into a unique per-connection set of short-term session keys.
   This secret may have been established in a previous handshake.  If
   PSK with (EC)DHE key establishment is used, these session keys will
   also be forward secret.  The resumption PSK has been designed so that
   the resumption master secret computed by connection N and needed to
   form connection N+1 is separate from the traffic keys used by
   connection N, thus providing forward secrecy between the connections.
   In addition, if multiple tickets are established on the same
   connection, they are associated with different keys, so compromise of
   the PSK associated with one ticket does not lead to the compromise of
   connections established with PSKs associated with other tickets.
   This property is most interesting if tickets are stored in a database
   (and so can be deleted) rather than if they are self-encrypted.

   The PSK binder value forms a binding between a PSK and the current
   handshake, as well as between the session where the PSK was
   established and the session where it was used.  This binding
   transitively includes the original handshake transcript, because that
   transcript is digested into the values which produce the Resumption
   Master Secret.  This requires that both the KDF used to produce the
   resumption master secret and the MAC used to compute the binder be
   collision resistant.  See Appendix E.1.1 for more on this.  Note: The
   binder does not cover the binder values from other PSKs, though they
   are included in the Finished MAC.

   Note: TLS does not currently permit the server to send a
   certificate_request message in non-certificate-based handshakes
   (e.g., PSK).  If this restriction were to be relaxed in future, the
   client's signature would not cover the server's certificate directly.
   However, if the PSK was established through a NewSessionTicket, the
   client's signature would transitively cover the server's certificate
   through the PSK binder.  [PSK-FINISHED] describes a concrete attack
   on constructions that do not bind to the server's certificate (see
   also [Kraw16]).  It is unsafe to use certificate-based client
   authentication when the client might potentially share the same PSK/
   key-id pair with two different endpoints.  Implementations MUST NOT
   combine external PSKs with certificate-based authentication of either
   the client or the server.

   If an exporter is used, then it produces values which are unique and
   secret (because they are generated from a unique session key).
   Exporters computed with different labels and contexts are
   computationally independent, so it is not feasible to compute one
   from another or the session secret from the exported value.  Note:
   exporters can produce arbitrary-length values.  If exporters are to
   be used as channel bindings, the exported value MUST be large enough
   to provide collision resistance.  The exporters provided in TLS 1.3

Rescorla                 Expires January 4, 2018              [Page 129]
Internet-Draft                     TLS                         July 2017

   are derived from the same handshake contexts as the early traffic
   keys and the application traffic keys respectively, and thus have
   similar security properties.  Note that they do not include the
   client's certificate; future applications which wish to bind to the
   client's certificate may need to define a new exporter that includes
   the full handshake transcript.

   For all handshake modes, the Finished MAC (and where present, the
   signature), prevents downgrade attacks.  In addition, the use of
   certain bytes in the random nonces as described in Section 4.1.3
   allows the detection of downgrade to previous TLS versions.  See
   [BBFKZG16] for more detail on TLS 1.3 and downgrade.

   As soon as the client and the server have exchanged enough
   information to establish shared keys, the remainder of the handshake
   is encrypted, thus providing protection against passive attackers,
   even if the computed shared key is not authenticated.  Because the
   server authenticates before the client, the client can ensure that if
   it authenticates to the server, it only reveals its identity to an
   authenticated server.  Note that implementations must use the
   provided record padding mechanism during the handshake to avoid
   leaking information about the identities due to length.  The client's
   proposed PSK identities are not encrypted, nor is the one that the
   server selects.

E.1.1.  Key Derivation and HKDF

   Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869]
   and its two components, HKDF-Extract and HKDF-Expand.  The full
   rationale for the HKDF construction can be found in [Kraw10] and the
   rationale for the way it is used in TLS 1.3 in [KW16].  Throughout
   this document, each application of HKDF-Extract is followed by one or
   more invocations of HKDF-Expand.  This ordering should always be
   followed (including in future revisions of this document), in
   particular, one SHOULD NOT use an output of HKDF-Extract as an input
   to another application of HKDF-Extract without an HKDF-Expand in
   between.  Consecutive applications of HKDF-Expand are allowed as long
   as these are differentiated via the key and/or the labels.

   Note that HKDF-Expand implements a pseudorandom function (PRF) with
   both inputs and outputs of variable length.  In some of the uses of
   HKDF in this document (e.g., for generating exporters and the
   resumption_master_secret), it is necessary that the application of
   HKDF-Expand be collision-resistant, namely, it should be infeasible
   to find two different inputs to HKDF-Expand that output the same
   value.  This requires the underlying hash function to be collision
   resistant and the output length from HKDF-Expand to be of size at

Rescorla                 Expires January 4, 2018              [Page 130]
Internet-Draft                     TLS                         July 2017

   least 256 bits (or as much as needed for the hash function to prevent
   finding collisions).

E.1.2.  Client Authentication

   A client that has sent authentication data to a server, either during
   the handshake or in post-handshake authentication, cannot be sure if
   the server afterwards considers the client to be authenticated or
   not.  If the client needs to determine if the server considers the
   connection to be unilaterally or mutually authenticated, this has to
   be provisioned by the application layer.  See [CHHSV17] for details.
   In addition, the analysis of post-handshake authentication from
   [Kraw16] shows that the client identified by the certificate sent in
   the post-handshake phase possesses the traffic key.  This party is
   therefore the client that participated in the original handshake or
   one to whom the original client delegated the traffic key (assuming
   that the traffic key has not been compromised).

E.1.3.  0-RTT

   The 0-RTT mode of operation generally provides similar security
   properties as 1-RTT data, with the two exceptions that the 0-RTT
   encryption keys do not provide full forward secrecy and that the
   server is not able to guarantee uniqueness of the handshake (non-
   replayability) without keeping potentially undue amounts of state.
   See Section 4.2.9 for one mechanism to limit the exposure to replay.

E.1.4.  Exporter Independence

   The exporter_master_secret and early_exporter_master_secret are
   derived to be independent of the traffic keys and therefore do not
   represent a threat to the security of traffic encrypted with those
   keys.  However, because these secrets can be used to compute any
   exporter value, they SHOULD be erased as soon as possible.  If the
   total set of exporter labels is known, then implementations SHOULD
   pre-compute the inner Derive-Secret stage of the exporter computation
   for all those labels, then erase the [early_]exporter_master_secret,
   followed by each inner values as soon as it is known that it will not
   be needed again.

E.1.5.  Post-Compromise Security

   TLS does not provide security for handshakes which take place after
   the peer's long-term secret (signature key or external PSK) is
   compromised.  It therefore does not provide post-compromise security
   [CCG16], sometimes also referred to as backwards or future secrecy.
   This is in contrast to KCI resistance, which describes the security

Rescorla                 Expires January 4, 2018              [Page 131]
Internet-Draft                     TLS                         July 2017

   guarantees that a party has after its own long-term secret has been
   compromised.

E.1.6.  External References

   The reader should refer to the following references for analysis of
   the TLS handshake: [DFGS15] [CHSV16] [DFGS16] [KW16] [Kraw16]
   [FGSW16] [LXZFH16] [FG17] [BBK17].

E.2.  Record Layer

   The record layer depends on the handshake producing strong traffic
   secrets which can be used to derive bidirectional encryption keys and
   nonces.  Assuming that is true, and the keys are used for no more
   data than indicated in Section 5.5 then the record layer should
   provide the following guarantees:

   Confidentiality.  An attacker should not be able to determine the
      plaintext contents of a given record.

   Integrity.  An attacker should not be able to craft a new record
      which is different from an existing record which will be accepted
      by the receiver.

   Order protection/non-replayability  An attacker should not be able to
      cause the receiver to accept a record which it has already
      accepted or cause the receiver to accept record N+1 without having
      first processed record N.

   Length concealment.  Given a record with a given external length, the
      attacker should not be able to determine the amount of the record
      that is content versus padding.

   Forward secrecy after key change.  If the traffic key update
      mechanism described in Section 4.6.3 has been used and the
      previous generation key is deleted, an attacker who compromises
      the endpoint should not be able to decrypt traffic encrypted with
      the old key.

   Informally, TLS 1.3 provides these properties by AEAD-protecting the
   plaintext with a strong key.  AEAD encryption [RFC5116] provides
   confidentiality and integrity for the data.  Non-replayability is
   provided by using a separate nonce for each record, with the nonce
   being derived from the record sequence number (Section 5.3), with the
   sequence number being maintained independently at both sides thus
   records which are delivered out of order result in AEAD deprotection
   failures.  In order to prevent mass cryptanalysis when the same
   plaintext is repeatedly encrypted by different users under the same

Rescorla                 Expires January 4, 2018              [Page 132]
Internet-Draft                     TLS                         July 2017

   key (as is commonly the case for HTTP), the nonce is formed by mixing
   the sequence number with a secret per-connection initialization
   vector derived along with the traffic keys.  See [BT16] for analysis
   of this construction.

   The re-keying technique in TLS 1.3 (see Section 7.2) follows the
   construction of the serial generator in [REKEY], which shows that re-
   keying can allow keys to be used for a larger number of encryptions
   than without re-keying.  This relies on the security of the HKDF-
   Expand-Label function as a pseudorandom function (PRF).  In addition,
   as long as this function is truly one way, it is not possible to
   compute traffic keys from prior to a key change (forward secrecy).

   TLS does not provide security for data which is communicated on a
   connection after a traffic secret of that connection is compromised.
   That is, TLS does not provide post-compromise security/future
   secrecy/backward secrecy with respect to the traffic secret.  Indeed,
   an attacker who learns a traffic secret can compute all future
   traffic secrets on that connection.  Systems which want such
   guarantees need to do a fresh handshake and establish a new
   connection with an (EC)DHE exchange.

E.2.1.  External References

   The reader should refer to the following references for analysis of
   the TLS record layer: [BMMT15] [BT16] [BDFKPPRSZZ16] [BBK17].

E.3.  Traffic Analysis

   TLS is susceptible to a variety of traffic analysis attacks based on
   observing the length and timing of encrypted packets [CLINIC]
   [HCJ16].  This is particularly easy when there is a small set of
   possible messages to be distinguished, such as for a video server
   hosting a fixed corpus of content, but still provides usable
   information even in more complicated scenarios.

   TLS does not provide any specific defenses against this form of
   attack but does include a padding mechanism for use by applications:
   The plaintext protected by the AEAD function consists of content plus
   variable-length padding, which allows the application to produce
   arbitrary length encrypted records as well as padding-only cover
   traffic to conceal the difference between periods of transmission and
   periods of silence.  Because the padding is encrypted alongside the
   actual content, an attacker cannot directly determine the length of
   the padding, but may be able to measure it indirectly by the use of
   timing channels exposed during record processing (i.e., seeing how
   long it takes to process a record or trickling in records to see
   which ones elicit a response from the server).  In general, it is not

Rescorla                 Expires January 4, 2018              [Page 133]
Internet-Draft                     TLS                         July 2017

   known how to remove all of these channels because even a constant
   time padding removal function will then feed the content into data-
   dependent functions.

   Note: Robust traffic analysis defences will likely lead to inferior
   performance due to delay in transmitting packets and increased
   traffic volume.

E.4.  Side Channel Attacks

   In general, TLS does not have specific defenses against side-channel
   attacks (i.e., those which attack the communications via secondary
   channels such as timing) leaving those to the implementation of the
   relevant cryptographic primitives.  However, certain features of TLS
   are designed to make it easier to write side-channel resistant code:

   -  Unlike previous versions of TLS which used a composite MAC-then-
      encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing
      implementations to use self-contained constant-time
      implementations of those primitives.

   -  TLS uses a uniform "bad_record_mac" alert for all decryption
      errors, which is intended to prevent an attacker from gaining
      piecewise insight into portions of the message.  Additional
      resistance is provided by terminating the connection on such
      errors; a new connection will have different cryptographic
      material, preventing attacks against the cryptographic primitives
      that require multiple trials.

   Information leakage through side channels can occur at layers above
   TLS, in application protocols and the applications that use them.
   Resistance to side-channel attacks depends on applications and
   application protocols separately ensuring that confidential
   information is not inadvertently leaked.

E.5.  Replay Attacks on 0-RTT

   Replayable 0-RTT data presents a number of security threats to TLS-
   using applications, unless those applications are specifically
   engineered to be safe under replay (minimally, this means idempotent,
   but in many cases may also require other stronger conditions, such as
   constant-time response).  Potential attacks include:

   -  Duplication of actions which cause side effects (e.g., purchasing
      an item or transferring money) to be duplicated, thus harming the
      site or the user.

Rescorla                 Expires January 4, 2018              [Page 134]
Internet-Draft                     TLS                         July 2017

   -  Attackers can store and replay 0-RTT messages in order to re-order
      them with respect to other messages (e.g., moving a delete to
      after a create).

   -  Exploiting cache timing behavior to discover the content of 0-RTT
      messages by replaying a 0-RTT message to a different cache node
      and then using a separate connection to measure request latency,
      to see if the two requests address the same resource.

   If data can be replayed a large number of times, additional attacks
   become possible, such as making repeated measurements of the the
   speed of cryptographic operations.  In addition, they may be able to
   overload rate-limiting systems.  For further description of these
   attacks, see [Mac17].

   Ultimately, servers have the responsibility to protect themselves
   against attacks employing 0-RTT data replication.  The mechanisms
   described in Section 8 are intended to prevent replay at the TLS
   layer do not provide complete protection against receiving multiple
   copies of client data.  TLS 1.3 falls back to the 1-RTT handshake
   when the server does not have any information about the client, e.g.,
   because it is in a different cluster which does not share state or
   because the ticket has been deleted as described in Section 8.1.  If
   the application layer protocol retransmits data in this setting, then
   it is possible for an attacker to induce message duplication by
   sending the ClientHello to both the original cluster (which processes
   the data immediately) and another cluster which will fall back to
   1-RTT and process the data upon application layer replay.  The scale
   of this attack is limited by the client's willingness to retry
   transactions and therefore only allows a limited amount of
   duplication, with each copy appearing as a new connection at the
   server.

   If implemented correctly, the mechanisms described in Section 8.1 and
   Section 8.2 prevent a replayed ClientHello and its associated 0-RTT
   data from being accepted multiple times by any cluster with
   consistent state; for servers which limit the use of 0-RTT to one
   cluster for a single ticket, then a given ClientHello and its
   associated 0-RTT data will only be accepted once.  However, if state
   is not completely consistent, then an attacker might be able to have
   multiple copies of the data be accepted during the replication
   window.  Because clients do not know the exact details of server
   behavior, they MUST NOT send messages in early data which are not
   safe to have replayed and which they would not be willing to retry
   across multiple 1-RTT connections.

   Application protocols MUST NOT use 0-RTT data without a profile that
   defines its use.  That profile needs to identify which messages or

Rescorla                 Expires January 4, 2018              [Page 135]
Internet-Draft                     TLS                         July 2017

   interactions are safe to use with 0-RTT and how to handle the
   situation when the server rejects 0-RTT and falls back to 1-RTT.

   In addition, to avoid accidental misuse, TLS implementations MUST NOT
   enable 0-RTT (either sending or accepting) unless specifically
   requested by the application and MUST NOT automatically resend 0-RTT
   data if it is rejected by the server unless instructed by the
   application.  Server-side applications may wish to implement special
   processing for 0-RTT data for some kinds of application traffic
   (e.g., abort the connection, request that data be resent at the
   application layer, or delay processing until the handshake
   completes).  In order to allow applications to implement this kind of
   processing, TLS implementations MUST provide a way for the
   application to determine if the handshake has completed.

E.5.1.  Replay and Exporters

   Replays of the ClientHello produce the same early exporter, thus
   requiring additional care by applications which use these exporters.
   In particular, if these exporters are used as an authentication
   channel binding (e.g., by signing the output of the exporter) an
   attacker who compromises the PSK can transplant authenticators
   between connections without compromising the authentication key.

   In addition, the early exporter SHOULD NOT be used to generate
   server-to-client encryption keys because that would entail the reuse
   of those keys.  This parallels the use of the early application
   traffic keys only in the client-to-server direction.

Appendix F.  Working Group Information

   The discussion list for the IETF TLS working group is located at the
   e-mail address tls@ietf.org [1].  Information on the group and
   information on how to subscribe to the list is at
   https://www.ietf.org/mailman/listinfo/tls

   Archives of the list can be found at: https://www.ietf.org/mail-
   archive/web/tls/current/index.html

Appendix G.  Contributors

   -  Martin Abadi
      University of California, Santa Cruz
      abadi@cs.ucsc.edu

   -  Christopher Allen (co-editor of TLS 1.0)
      Alacrity Ventures
      ChristopherA@AlacrityManagement.com

Rescorla                 Expires January 4, 2018              [Page 136]
Internet-Draft                     TLS                         July 2017

   -  Steven M.  Bellovin
      Columbia University
      smb@cs.columbia.edu

   -  David Benjamin
      Google
      davidben@google.com

   -  Benjamin Beurdouche
      INRIA & Microsoft Research
      benjamin.beurdouche@ens.fr

   -  Karthikeyan Bhargavan (co-author of [RFC7627])
      INRIA
      karthikeyan.bhargavan@inria.fr

   -  Simon Blake-Wilson (co-author of [RFC4492])
      BCI
      sblakewilson@bcisse.com

   -  Nelson Bolyard (co-author of [RFC4492])
      Sun Microsystems, Inc.
      nelson@bolyard.com

   -  Ran Canetti
      IBM
      canetti@watson.ibm.com

   -  Matt Caswell
      OpenSSL
      matt@openssl.org

   -  Pete Chown
      Skygate Technology Ltd
      pc@skygate.co.uk

   -  Katriel Cohn-Gordon
      University of Oxford
      me@katriel.co.uk

   -  Cas Cremers
      University of Oxford
      cas.cremers@cs.ox.ac.uk

   -  Antoine Delignat-Lavaud (co-author of [RFC7627])
      INRIA
      antoine.delignat-lavaud@inria.fr

Rescorla                 Expires January 4, 2018              [Page 137]
Internet-Draft                     TLS                         July 2017

   -  Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
      Independent
      tim@dierks.org

   -  Taher Elgamal
      Securify
      taher@securify.com

   -  Pasi Eronen
      Nokia
      pasi.eronen@nokia.com

   -  Cedric Fournet
      Microsoft
      fournet@microsoft.com

   -  Anil Gangolli
      anil@busybuddha.org

   -  David M.  Garrett
      dave@nulldereference.com

   -  Alessandro Ghedini
      Cloudflare Inc.
      alessandro@cloudflare.com

   -  Daniel Kahn Gillmor
      ACLU
      dkg@fifthhorseman.net

   -  Matthew Green
      Johns Hopkins University
      mgreen@cs.jhu.edu

   -  Jens Guballa
      ETAS
      jens.guballa@etas.com

   -  Felix Guenther
      TU Darmstadt
      mail@felixguenther.info

   -  Vipul Gupta (co-author of [RFC4492])
      Sun Microsystems Laboratories
      vipul.gupta@sun.com

   -  Chris Hawk (co-author of [RFC4492])
      Corriente Networks LLC

Rescorla                 Expires January 4, 2018              [Page 138]
Internet-Draft                     TLS                         July 2017

      chris@corriente.net

   -  Kipp Hickman

   -  Alfred Hoenes

   -  David Hopwood
      Independent Consultant
      david.hopwood@blueyonder.co.uk

   -  Marko Horvat
      MPI-SWS
      mhorvat@mpi-sws.org

   -  Jonathan Hoyland
      Royal Holloway, University of London

   -  Subodh Iyengar
      Facebook
      subodh@fb.com

   -  Benjamin Kaduk
      Akamai
      kaduk@mit.edu

   -  Hubert Kario
      Red Hat Inc.
      hkario@redhat.com

   -  Phil Karlton (co-author of SSL 3.0)

   -  Leon Klingele
      Independent
      mail@leonklingele.de

   -  Paul Kocher (co-author of SSL 3.0)
      Cryptography Research
      paul@cryptography.com

   -  Hugo Krawczyk
      IBM
      hugokraw@us.ibm.com

   -  Adam Langley (co-author of [RFC7627])
      Google
      agl@google.com

   -  Olivier Levillain

Rescorla                 Expires January 4, 2018              [Page 139]
Internet-Draft                     TLS                         July 2017

      ANSSI
      olivier.levillain@ssi.gouv.fr

   -  Xiaoyin Liu
      University of North Carolina at Chapel Hill
      xiaoyin.l@outlook.com

   -  Ilari Liusvaara
      Independent
      ilariliusvaara@welho.com

   -  Atul Luykx
      K.U.  Leuven
      atul.luykx@kuleuven.be

   -  Colm MacCarthaigh
      Amazon Web Services
      colm@allcosts.net

   -  Carl Mehner
      USAA
      carl.mehner@usaa.com

   -  Jan Mikkelsen
      Transactionware
      janm@transactionware.com

   -  Bodo Moeller (co-author of [RFC4492])
      Google
      bodo@openssl.org

   -  Kyle Nekritz
      Facebook
      knekritz@fb.com

   -  Erik Nygren
      Akamai Technologies
      erik+ietf@nygren.org

   -  Magnus Nystrom
      Microsoft
      mnystrom@microsoft.com

   -  Kazuho Oku
      DeNA Co., Ltd.
      kazuhooku@gmail.com

   -  Kenny Paterson

Rescorla                 Expires January 4, 2018              [Page 140]
Internet-Draft                     TLS                         July 2017

      Royal Holloway, University of London
      kenny.paterson@rhul.ac.uk

   -  Alfredo Pironti (co-author of [RFC7627])
      INRIA
      alfredo.pironti@inria.fr

   -  Andrei Popov
      Microsoft
      andrei.popov@microsoft.com

   -  Marsh Ray (co-author of [RFC7627])
      Microsoft
      maray@microsoft.com

   -  Robert Relyea
      Netscape Communications
      relyea@netscape.com

   -  Kyle Rose
      Akamai Technologies
      krose@krose.org

   -  Jim Roskind
      Amazon
      jroskind@amazon.com

   -  Michael Sabin

   -  Joe Salowey
      Tableau Software
      joe@salowey.net

   -  Rich Salz
      Akamai
      rsalz@akamai.com

   -  Sam Scott
      Royal Holloway, University of London
      me@samjs.co.uk

   -  Dan Simon
      Microsoft, Inc.
      dansimon@microsoft.com

   -  Brian Smith
      Independent
      brian@briansmith.org

Rescorla                 Expires January 4, 2018              [Page 141]
Internet-Draft                     TLS                         July 2017

   -  Brian Sniffen
      Akamai Technologies
      ietf@bts.evenmere.org

   -  Nick Sullivan
      Cloudflare Inc.
      nick@cloudflare.com

   -  Bjoern Tackmann
      University of California, San Diego
      btackmann@eng.ucsd.edu

   -  Tim Taubert
      Mozilla
      ttaubert@mozilla.com

   -  Martin Thomson
      Mozilla
      mt@mozilla.com

   -  Sean Turner
      sn3rd
      sean@sn3rd.com

   -  Filippo Valsorda
      Cloudflare Inc.
      filippo@cloudflare.com

   -  Thyla van der Merwe
      Royal Holloway, University of London
      tjvdmerwe@gmail.com

   -  Tom Weinstein

   -  Hoeteck Wee
      Ecole Normale Superieure, Paris
      hoeteck@alum.mit.edu

   -  David Wong
      NCC Group
      david.wong@nccgroup.trust

   -  Tim Wright
      Vodafone
      timothy.wright@vodafone.com

   -  Kazu Yamamoto
      Internet Initiative Japan Inc.

Rescorla                 Expires January 4, 2018              [Page 142]
Internet-Draft                     TLS                         July 2017

      kazu@iij.ad.jp

Author's Address

   Eric Rescorla
   RTFM, Inc.

   EMail: ekr@rtfm.com

Rescorla                 Expires January 4, 2018              [Page 143]