Token Binding Working Group                                    N. Harper
Internet-Draft                                               Google Inc.
Intended status: Standards Track                          March 13,                           June 28, 2017
Expires: September 14, December 30, 2017

              Token Binding for 0-RTT TLS 1.3 Connections
                    draft-ietf-tokbind-tls13-0rtt-01
                    draft-ietf-tokbind-tls13-0rtt-02

Abstract

   This document describes how Token Binding can be used in the 0-RTT
   data of a TLS 1.3 connection.  This involves updating how a new TLS extension to
   negotiate and indicate the use of Token Binding negotiation works and adding a mechanism for indicating
   whether a server prevents replay. in 0-RTT data.  A
   TokenBindingMessage sent in 0-RTT data has different security
   properties than one sent after the TLS handshake has finished, which
   this document also describes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, December 30, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2   3
   2.  Proposed Design  TokenBinding Signature Definition . . . . . . . . . . . . . .   3
     2.1.  Selecting Which Exporter Secret to Use  . . . . . . . . .   3
     2.1.  TokenBinding Signature Definition
   3.  Negotiation . . . . . . . . . . . .   3
       2.1.1.  Selecting Which Exporter Secret to Use . . . . . . .   3
     2.2.  Negotiating Token Binding . . . . . .   4
     3.1.  Indicating Use of 0-RTT Token Binding . . . . . . . . . .   4
       2.2.1.
     3.2.  Token Binding Negotiation TLS Extension . . . . . . . . .   4
     3.3.  Client Processing Rules . . . . . . .   4
       2.2.2.  Replay Protection Indication Extension . . . . . . .   4
   3.  Implementation Challenges . . .   4
     3.4.  Server Processing Rules . . . . . . . . . . . . . . . . .   5
   4.  IANA  Implementation Considerations . . . . . . . . . . . . . . . .   6
     4.1.  Not Implementing Token Binding on 0-RTT Connections . . .   6
     4.2.  Adding Support for Token Binding on 0-RTT Connections . .   7
     4.3.  Implementation Challenges .   5 . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.1.   8
     6.1.  Proof of Possession of Token Binding Key  . . . . . . . .   6
     5.2.  Attacks on PSK-only Key Exchange and Token Binding  . . .   6
     5.3.   8
     6.2.  Exporter Replayability  . . . . . . . . . . . . . . . . .   7
     5.4.   8
     6.3.  Replay Mitigations  . . . . . . . . . . . . . . . . . . .   7
       5.4.1.   9
       6.3.1.  Server Mitigations  . . . . . . . . . . . . . . . . .   8
       5.4.2.   9
       6.3.2.  Client Mitigations  . . . . . . . . . . . . . . . . .   8
     5.5.  10
     6.4.  Early Data Ticket Age Window  . . . . . . . . . . . . . .   8
   6.  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   9  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9  11

1.  Introduction

   Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds
   security tokens (e.g.  HTTP cookies, OAuth tokens) to the TLS layer
   on which they are presented.  It does so by signing an [RFC5705]
   exporter value from the TLS connection.  TLS 1.3 introduces a new
   mode that allows a client to send application data on its first
   flight.  If this 0-RTT data contains a security token, then a client
   using Token Binding would want to prove possession of its Token
   Binding private key so that the server can verify the binding.  The
   [RFC5705]-style exporter provided by TLS 1.3 cannot be run until the
   handshake has finished.  TLS 1.3 also provides an exporter that can
   be used with 0-RTT data, but it requires that the application
   explicitly specify that use.  This document specifies how to use the
   early_exporter_secret with Token Binding in TLS 1.3 0-RTT data.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Proposed Design

   A TokenBinding struct as defined

   Using Token Binding in [I-D.ietf-tokbind-protocol]
   contains a signature of the EKM value from the TLS layer.  Under
   normal circumstances, a TokenBinding on a TLS 1.3 connection would
   use the exporter_secret to derive the EKM value.  When 0-RTT data is
   assembled involves two main changes to be sent, the exporter_secret Token
   Binding.  The first is not yet available.  This
   design changes the definition use of the TokenBinding.signature field a new TLS extension
   "early_token_binding" to
   use the exporter with either early_exporter_secret or
   exporter_secret.  Since no negotiation for the connection indicate whether a TLS session ticket can happen
   before the client sends this TokenBindingMessage be
   used with Token Binding in 0-RTT data, this
   document also describes how a client decides what TokenBindingMessage and to send indicate whether an
   attempted 0-RTT connection is using Token Binding in 0-RTT data and how a server should interpret data.  The
   second change is one that message. applies only if Token Binding in 0-RTT data
   is in use, which changes the definition of the TokenBinding.signature
   field to use TLS 1.3's early_exporter_secret.

   If a client does not send any 0-RTT data, or if the server rejects
   the client's 0-RTT data, then the client MUST use the 1-RTT exporter,
   as defined in [I-D.ietf-tokbind-protocol].

2.1.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  TokenBinding Signature Definition

   In [I-D.ietf-tokbind-protocol], the signature field of the
   TokenBinding struct is defined to be the signature of a
   concatentation that includes the EKM value.  Depending on the
   circumstances, the exporter value in section 7.3.3 of
   [I-D.ietf-tls-tls13] is computed using either exporter_secret or
   early_exporter_secret as the Secret.

   When early_exporter_secret is used as the Secret, the client MUST
   indicate this use so the server knows which secret to use in
   signature verification.  This indication is done through a new Token
   Binding extension, "early_exporter" (with extension type TBD).  This
   extension always has 0-length data, so the full Extension struct is
   the bytes {0xTBD, 0x00, 0x00}. The early_exporter extension MUST be
   present in every TokenBinding struct where the exporter that is
   signed uses the early_exporter_secret, and it MUST NOT be present in
   any other TokenBinding structs.

2.1.1.

2.1.  Selecting Which Exporter Secret to Use

   A client which is not sending any 0-RTT data on a connection MUST use
   the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret
   as the Secret) for all TokenBindingMessages on that connection so
   that it is compatible with [I-D.ietf-tokbind-protocol].

   When a client sends a TokenBindingMessage in 0-RTT data, it must use
   the early_exporter_secret.  After  If the client receives an application-
   layer response from server accepts the server, it 0-RTT data, the
   client must continue to use the exporter_secret early_exporter_secret for
   all future token bindings on that connection.  Requests sent after the client's TLS Finished message, but before rest of
   the client processes
   any application-layer response from connection.  If the server, may use either
   exporter secret in their token bindings.

   A server may choose to reject an application message containing a
   Token Binding that uses the early_exporter_secret.  If it chooses to
   do so, it may send an application message indicating that rejects 0-RTT data, the client
   should re-send must
   use the request (with a new Token Binding).  In HTTP, this
   could be done with a 307 status code.

2.2.  Negotiating Token Binding

2.2.1. exporter_secret.

3.  Negotiation TLS Extension

   The behavior

3.1.  Indicating Use of the 0-RTT Token Binding negotiation

   The TLS extension does not
   change for a 0-RTT connection: "early_token_binding" (extension type TBD) is used
   in the client TLS ClientHello and server should process
   this extension the same way regardless EncryptedExtensions to indicate use of whether
   0-RTT Token Binding on the client current connection.  It is also
   sent the EarlyDataIndication extension.

   For the sake of choosing used in a key parameter
   NewSessionTicket message to use in 0-RTT data, the
   client MUST use the same key parameter indicate that was 0-RTT Token Binding may be
   used on the a connection during which resumed with that ticket.  In all cases, the ticket (now being used for resumption)
   was established.  The
   "extension_data" field of this extension is empty, so the entire
   encoding of this extension is 0xTBD 0xTBD 0x00 0x00.

3.2.  Token Binding Negotiation TLS Extension

   In TLS 1.3, the "token_binding" extension is sent by a server MUST NOT accept early in
   EncryptedExtensions, whereas in previous versions of TLS this
   extension was sent in the ServerHello message.  On a 1-RTT connection
   (whether it be a new connection or resumption), no application data if
   is sent in either direction before the
   negotiated "token_binding" TLS extension
   in the EncryptedExtensions, and the choice of Token Binding version
   and key parameter does not match is up to the parameter
   from server based on what the initial connection.  This is client sent
   and what the server's preferences are, following the same behavior processing
   rules as ALPN and
   SNI extensions.

   If 0-RTT data is being sent with in [I-D.ietf-tokbind-negotiation].

3.3.  Client Processing Rules

   A client that supports Token Binding using in 0-RTT data and receives a PSK obtained
   out-of-band, then
   NewSessionTicket containing the "early_token_binding" extension must
   store with the ticket the Token Binding key parameter to use with that
   PSK must also be provisioned to both parties, version and only that key parameter must be used with that PSK.

2.2.2.  Replay Protection Indication Extension

   The signed exporter value used of
   the connection in which the ticket was issued.

   A client that wishes to send a Token Binding message in 0-RTT data
   may only do so if the TLS connection is not
   guaranteed to be unique to in which the connection, so an attacker may be able
   to replay 0-RTT data is being
   sent is being resumed from a ticket which included the signature without having possession of
   "early_token_binding" extension.  Assuming the private key.
   To combat ticket included this attack,
   extension, the client sends a ClientHello containing the
   "token_binding" extension, "early_data" extension, and
   "early_token_binding" extensions.  The client must include in its
   "psk_key_exchange_modes" extension psk_dhe_ke.

   The contents of the "token_binding" extension SHOULD be the same as
   they would be on a connection without "early_token_binding" to allow
   for the client and server to negotiate new Token Binding parameters
   if the early data is rejected.  The Token Binding message sent in the
   0-RTT data MUST be sent assuming that the same Token Binding version
   and key parameter from the connection where the ticket was received
   will also be negotiated on this connection.  If the server includes
   the "early_data" extension in EncryptedExtensions in response to a
   ClientHello with "early_token_binding", but the server does not
   include "early_token_binding" in EncryptedExtensions, or if the
   server's "token_binding" extension does not match the values of the
   connection where the ticket was received, then the client MUST
   terminate the TLS connection with an illegal_parameter alert.

   It is valid for a client to send a ClientHello that contains both the
   "early_data" and "token_binding" extensions, but without the
   "early_token_binding" extension.  This combination means that the
   client is attempting to resume a connection and is sending early
   data, but the client is not using Token Binding on this resumed
   connection (if the server accepts the early data).  The presence of
   the "token_binding" extension is so the client can negotiate the use
   of Token Binding for this connection if the server rejects early
   data.

3.4.  Server Processing Rules

   When a server issues a NewSessionTicket on a connection where Token
   Binding was negotiated, and the NewSessionTicket includes an
   "early_data" extension indicating that the ticket may be used to send
   0-RTT data, the server may also include the "early_token_binding"
   extension in the NewSessionTicket to indicate that this ticket can be
   used for a future connection with Token Binding in 0-RTT data.  If
   the server includes the "early_token_binding" extension in the
   NewSessionTicket, the server MUST store with the ticket the Token
   Binding version and key parameter used for the connection in which
   the ticket was issued.  The "early_token_binding" extension can
   appear in a NewSessionTicket message only if the "early_data"
   extension also appears in that message.

   If a server receives a ClientHello with the "early_token_binding"
   extension and supports Token Binding in 0-RTT data, it MUST perform
   the following checks:

   o  If either the "early_data" or "token_binding" extensions are
      missing from the ClientHello, terminate the TLS connection with an
      illegal_parameter alert.

   o  If the ticket used for resumption is missing either of the
      "early_data" or "early_token_binding" extensions, reject the early
      data.

   o  Process the "token_binding" extension as if it were received on a
      1-RTT connection and compute the Token Binding version and key
      parameter to use.  If either of these values do not match the
      values that were negotiated on the connection where the ticket
      used for resumption was sent, reject the early data.

   o  Perform any other checks to decide whether to accept early data.
      If the server chooses to accept early data, include in
      EncryptedExtensions the "early_data" extension,
      "early_token_binding" extension, and "token_binding" extension
      with the same version and key parameter from the previous
      connection.

   If a server accepts early data on a connection where
   "early_token_binding" was offered, it MUST use PSK with (EC)DHE key
   establishment.

   The "early_token_binding" extension must be present in
   EncryptedExtensions exactly when both "early_data" and
   "token_binding" are present.  A server that receives a ClientHello
   with "early_token_binding" cannot reject Token Binding and also
   accept early data at the same time.  Said server may implement some sort reject early
   data but still negotiate Token Binding.

   A server might receive a ClientHello that includes both the
   "early_data" and "token_binding" extensions, but no
   "early_token_binding" extension.  In this case, the server has three
   options:

   1.  Accept early data and continue the connection with no Token
       Binding,

   2.  Reject early data and negotiate the use of replay
   prevention, Token Binding for this
       connection, or

   3.  Reject early data and indicate do not negotiate Token Binding for this to
       connection.

   The behavior for the client.  A new TLS "token_binding" extension
   "token_binding_replay_indication" in 0-RTT is defined for similar to
   that of ALPN and SNI: the client to query predicts the result of the
   negotiation, and if the actual negotiation differs, the server to indicate whether it
   rejects the early data.

4.  Implementation Considerations

4.1.  Not Implementing Token Binding on 0-RTT Connections

   This spec has implemented a mechanism been designed so that both clients and servers can
   support Token Binding on some connections and 0-RTT data on other
   connections without needing to
   prevent replay.

   enum {
       token_binding_replay_indication(TBD), (65535)
   } ExtensionType;
   When sent, this extension always has zero length.  If a support Token Binding on 0-RTT
   connections.

   A client that wishes to know whether its peer is preventing replay of TokenBinding structs
   across multiple connections, support both without supporting Token Binding
   on 0-RTT connections can function by completely ignoring the
   "early_token_binding" TLS extension.  When resuming a connection with
   early data, the client can include this still advertise support for Token Binding,
   providing the server the opportunity to accept early data (without
   Token Binding) or to reject early data and negotiate Token Binding.
   By always including the "token_binding" extension in its ClientHello.  Upon receiving this extension, ClientHello,
   the server must echo
   it back if it is using such a mechanism (like those described in
   Section 5.4.1) to prevent replay.  A client that only wishes to send can prioritize Token Binding over 0-RTT.

   A server can support both Token Binding and 0-RTT data without
   supporting Token Binding if on 0-RTT connections by never minting
   NewSessionTickets containing the "early_token_binding" extension.
   Such a server implements replay protection that never mints NewSessionTickets with
   "early_token_binding" can
   send this ignore that extension on first connection establishment, and in a ClientHello as
   it would only appear if the client is not spec compliant.  On
   connections where a server negotiates Token Binding, the server
   SHOULD NOT include the "early_data" extension in a NewSessionTicket.

4.2.  Adding Support for Token Binding on 0-RTT Connections

   A server doesn't send it back (but does support that supports early data but not Token Binding) the
   client can choose Binding may wish to not send
   add support for Token Binding (and Token Binding on 0-RTT messages to that server.

   A
   connections) at a later time.  For a client to learn that wishes a server
   supports Token Binding, the server must reject early data to use this extension should send it every time
   it sends a the
   "token_binding" [I-D.ietf-tokbind-negotiation] extension.

3.

4.3.  Implementation Challenges

   The client has to be able to modify the message it sends in 0-RTT
   data if the 0-RTT data gets rejected and needs to be retransmitted in
   1-RTT data.  Even if the Token Binding integration with 0-RTT were
   modified so that Token Binding never caused a 0-RTT reject that
   required rewriting a request, the client still has to handle the
   server rejecting the 0-RTT data for other reasons.

   HTTP2 allows for requests to different domains to share the same TLS
   connection if the SAN of the cert covers those domains.  If
   one.example.com supports 0-RTT and Token Binding, but two.example.com
   only supports Token Binding as defined in
   [I-D.ietf-tokbind-protocol], those servers cannot share a cert and
   use HTTP2.

4.

5.  IANA Considerations

   This document defines a new TLS extension
   "token_binding_replay_indication", "early_token_binding" with
   code point TBD which needs to be added to the
   IANA "Transport Layer Security (TLS) Extensions" IANA's TLS "ExtensionType
   Values" registry.

   This document defines a new Token Binding extension "early_exporter",
   which needs to be added to the IANA "Token Binding Extensions"
   registry.

5.

6.  Security Considerations

   Token Binding messages that use the 0-RTT exporter have weaker
   security properties than with the [RFC5705] exporter.  If either
   party of a connection using Token Binding does not wish to use 0-RTT
   token bindings, they can do so: a client can choose to never send
   0-RTT data on a connection where it uses token binding, and a server
   can choose to reject any 0-RTT data sent on a connection that
   negotiated token binding.

   0-RTT data in TLS 1.3 has weaker security properties than other kinds
   of TLS data.  Specifically, TLS 1.3 does not guarantee non-
   replayability of data between connections.  Token Binding has similar
   replayability issues when in 0-RTT data, but preventing replay of
   Token Binding and preventing replay of 0-RTT data are two separate
   problems.  Token Binding is not designed to prevent replay of 0-RTT
   data, although solutions for preventing the replay of Token Binding
   might also be applicable to 0-RTT data.

5.1.

6.1.  Proof of Possession of Token Binding Key

   When a Token Binding signature is generated using the exporter with
   early_exporter_secret, the value being signed is under the client's
   control.  An attacker with temporary access to the Token Binding
   private key can generate Token Binding signatures for as many future
   connections as it has NewSessionTickets for.  An attacker can
   construct these to be usable at any time in the future up until the
   NewSessionTicket's expiration.  Section 4.6.1 of [I-D.ietf-tls-tls13]
   requires that a NewSessionTicket be valid for a maximum of 7 days.

   Unlike in [I-D.ietf-tokbind-protocol], where the proof of possession
   of the Token Binding key proves that the client had possession at the
   time the TLS handshake finished, 0-RTT Token Binding only proves that
   the client had possession of the Token Binding key at some point
   after receiving the NewSessionTicket used for that connection.

5.2.  Attacks on PSK-only Key Exchange and Token Binding

   An attacker who possesses the PSK can eavesdrop on an existing
   connection that uses that PSK to obtain a TokenBindingMessage that is
   valid on the connection and then hijack the connection to send
   whatever attacker-controlled data it wishes.  Because the regular
   exporter closes over the server random, this TokenBindingMessage is
   valid only for that connection.

   If the attacker does the same thing with a pure-PSK connection and
   0-RTT Token Binding, the attacker can replay the original ClientHello
   and the exporter will stay the same, allowing the attacker to obtain
   a TokenBindingMessage from one connection and replay it on future
   connections.  The only way for a server to prevent this replay is to
   prevent the client from ever repeating a client random in the
   handshake.

   If a server accepting connections with PSK-only key establishment is
   concerned about the threat of PSK theft and also implements Token
   Binding, then that server must either reject all 0-RTT token
   bindings, or implement some form of preventing reuse of a client
   random.

5.3.

6.2.  Exporter Replayability

   The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so
   that a client and server have the same exporter value only if they
   are on the same TLS connection.  This prevents an attacker who can
   read the plaintext of a TokenBindingMessage sent on that connection
   from replaying that message on another connection (without also
   having the token binding private key).  The 0-RTT exporter only
   covers the ClientHello and the PSK of the connection, so it does not
   provide this guarantee.

   An attacker with possession of the PSK secret and a transcript of the
   ClientHello and early data sent by a client under that PSK can
   extract the TokenBindingMessage, create a new connection to the
   server (using the same ClientHello and PSK), and send different
   application data with the same TokenBindingMessage.  Note that the
   ClientHello contains public values for the (EC)DHE key agreement that
   is used as part of deriving the traffic keys for the TLS connection,
   so if the attacker does not also have the corresponding private
   values, they will not be able to read the server's response or send a
   valid Finished message in the handshake for this TLS connection.
   Nevertheless, by that point the server has already processed the
   attacker's message with the replayed TokenBindingMessage.

   This sort of replayability of a TokenBindingMessage is different than
   the replayability caveat of 0-RTT application data in TLS 1.3.  A
   network observer can replay 0-RTT data from TLS 1.3 without knowing
   any secrets of the client or server, but the application data that is
   replayed is untouched.  This replay is done by a more powerful
   attacker who is able to view the plaintext and then spoof a
   connection with the same parameters so that the replayed
   TokenBindingMessage still validates when sent with different
   application data.

5.4.

6.3.  Replay Mitigations

   This section presents multiple ways that a client or server can
   prevent
   mitigate the replay of a TokenBinding while still using Token Binding
   with 0-RTT data.

   If a client or server implements a measure that prevents all replays,
   then its peer does not also need to implement such a mitigation.  A
   client that is concerned about replay SHOULD implement a replay
   mitigation instead of relying solely on a signal from the server
   through the replay indication extension.  Note that even with replay mitigations, 0-RTT Token
   Binding is vulnerable to other attacks.

5.4.1.

6.3.1.  Server Mitigations

   If a server uses a session cache instead of stateless tickets, it can
   enforce that a PSK generated for resumption can only be used once.
   If an attacker tries to replay 0-RTT data (with a
   TokenBindingMessage), the server will reject it because the PSK was
   already used.

   Preventing all replay of 0-RTT data is not necessary to prevent
   replay of a TokenBinding.  A server could implement a mechanism to
   prevent a particular TokenBinding from being presented on more than
   one connection.  In cases where a server's TLS termination and
   application layer processing happen in different locations, this
   option might be easier to implement, especially when not all requests
   have bound tokens.  This processing can also take advantage of the
   structure of the bound token, e.g. a token that identifies which user
   is making a request could shard its store of which TokenBindings have
   been seen based on the user ID.

   A server can prevent some, but not all, 0-RTT data replay with a
   tight time window for the ticket age that it will accept.  See
   Section 5.5 6.4 for more details.

5.4.2.

6.3.2.  Client Mitigations

   A client cannot prevent a sufficiently motivated attacker from
   replaying a TokenBinding, but it can make it so difficult to replay
   the TokenBinding that it is easier for the attacker to steal the
   Token Binding key directly.  If the client secures the resumption
   secret with the same level of protection as the Token Binding key,
   then the client has made it not worth the effort of the attacker to
   attempt to replay a TokenBinding.  Ideally the resumption secret (and
   Token Binding key) are protected strongly and virtually non-
   exportable.

5.5.

6.4.  Early Data Ticket Age Window

   When an attacker with control of the PSK secret replays a
   TokenBindingMessage, it has to use the same ClientHello that the
   client used.  The ClientHello includes an "obfuscated_ticket_age" in
   its EarlyDataIndication extension, which the server can use to narrow
   the window in which that ClientHello will be accepted.  Even if a PSK
   is valid for a week, the server will only accept that particular
   ClientHello for a smaller time window based on the ticket age.  A
   server should make their acceptance window for this value as small as
   practical to limit an attacker's ability to replay a ClientHello and
   send new application data with the stolen TokenBindingMessage.

6.

7.  Acknowledgements

   The author would like to thank David Benjamin, Steven Valdez, Bill
   Cox, and Andrei Popov for their feedback and suggestions.

7.

8.  Normative References

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-19 draft-ietf-tls-tls13-20 (work in progress),
              March
              April 2017.

   [I-D.ietf-tokbind-negotiation]
              Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
              "Transport Layer Security (TLS) Extension for Token
              Binding Protocol Negotiation", draft-ietf-tokbind-
              negotiation-07
              negotiation-08 (work in progress), February April 2017.

   [I-D.ietf-tokbind-protocol]
              Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
              Hodges, "The Token Binding Protocol Version 1.0", draft-
              ietf-tokbind-protocol-13
              ietf-tokbind-protocol-14 (work in progress), February April 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>.

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

Author's Address

   Nick Harper
   Google Inc.

   Email: nharper@google.com