draft-ietf-tokbind-tls13-0rtt-00.txt   draft-ietf-tokbind-tls13-0rtt-01.txt 
Token Binding Working Group N. Harper Token Binding Working Group N. Harper
Internet-Draft Google Inc. Internet-Draft Google Inc.
Intended status: Standards Track November 17, 2016 Intended status: Standards Track March 13, 2017
Expires: May 21, 2017 Expires: September 14, 2017
Token Binding for 0-RTT TLS 1.3 Connections Token Binding for 0-RTT TLS 1.3 Connections
draft-ietf-tokbind-tls13-0rtt-00 draft-ietf-tokbind-tls13-0rtt-01
Abstract Abstract
This document describes how Token Binding can be used in the 0-RTT This document describes how Token Binding can be used in the 0-RTT
data of a TLS 1.3 connection. This involves updating how Token data of a TLS 1.3 connection. This involves updating how Token
Binding negotiation works and adding a mechanism for indicating Binding negotiation works and adding a mechanism for indicating
whether a server prevents replay. A TokenBindingMessage sent in whether a server prevents replay. A TokenBindingMessage sent in
0-RTT data has different security properties than one sent after the 0-RTT data has different security properties than one sent after the
TLS handshake has finished, which this document also describes. TLS handshake has finished, which this document also describes.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Proposed Design . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Design . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. TokenBinding Signature Definition . . . . . . . . . . . . 3 2.1. TokenBinding Signature Definition . . . . . . . . . . . . 3
2.1.1. Selecting Which Exporter Secret to Use . . . . . . . 3
2.2. Negotiating Token Binding . . . . . . . . . . . . . . . . 4 2.2. Negotiating Token Binding . . . . . . . . . . . . . . . . 4
2.2.1. Negotiation TLS Extension . . . . . . . . . . . . . . 4 2.2.1. Negotiation TLS Extension . . . . . . . . . . . . . . 4
2.2.2. Replay Protection Indication Extension . . . . . . . 4 2.2.2. Replay Protection Indication Extension . . . . . . . 4
3. Implementation Challenges . . . . . . . . . . . . . . . . . . 5 3. Implementation Challenges . . . . . . . . . . . . . . . . . . 5
4. Alternatives Considered . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Use Both 0-RTT and 1-RTT Exporters on Same Connection . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4.2. Don't Remember Key Parameter From Previous Connection . . 6 5.1. Proof of Possession of Token Binding Key . . . . . . . . 6
4.3. Token Binding and 0-RTT Data Are Mutually Exclusive . . . 6 5.2. Attacks on PSK-only Key Exchange and Token Binding . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.3. Exporter Replayability . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5.4. Replay Mitigations . . . . . . . . . . . . . . . . . . . 7
6.1. Attacks on PSK-only Key Exchange and Token Binding . . . 7 5.4.1. Server Mitigations . . . . . . . . . . . . . . . . . 8
6.2. Exporter Replayability . . . . . . . . . . . . . . . . . 7 5.4.2. Client Mitigations . . . . . . . . . . . . . . . . . 8
6.3. Replay Mitigations . . . . . . . . . . . . . . . . . . . 8 5.5. Early Data Ticket Age Window . . . . . . . . . . . . . . 8
6.3.1. Server Mitigations . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6.3.2. Client Mitigations . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . 9
6.4. Early Data Ticket Age Window . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
6.5. Lack of Freshness . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds Token Binding ([I-D.ietf-tokbind-protocol]) cryptographically binds
security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer security tokens (e.g. HTTP cookies, OAuth tokens) to the TLS layer
on which they are presented. It does so by signing an [RFC5705] on which they are presented. It does so by signing an [RFC5705]
exporter value from the TLS connection. TLS 1.3 introduces a new exporter value from the TLS connection. TLS 1.3 introduces a new
mode that allows a client to send application data on its first 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 flight. If this 0-RTT data contains a security token, then a client
using Token Binding would want to prove possession of its Token using Token Binding would want to prove possession of its Token
skipping to change at page 3, line 19 skipping to change at page 3, line 13
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Proposed Design 2. Proposed Design
A TokenBinding struct as defined in [I-D.ietf-tokbind-protocol] A TokenBinding struct as defined in [I-D.ietf-tokbind-protocol]
contains a signature of the EKM value from the TLS layer. Under contains a signature of the EKM value from the TLS layer. Under
normal circumstances, a TokenBinding on a TLS 1.3 connection would 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 use the exporter_secret to derive the EKM value. When 0-RTT data is
assembled to be sent, the exporter_secret is not yet available. This assembled to be sent, the exporter_secret is not yet available. This
design changes the definition of the TokenBinding.signature field to design changes the definition of the TokenBinding.signature field to
use the exporter with early_exporter_secret for 0-RTT data. Since no use the exporter with either early_exporter_secret or
negotiation for the connection can happen before the client sends exporter_secret. Since no negotiation for the connection can happen
this TokenBindingMessage in 0-RTT data, this document also describes before the client sends this TokenBindingMessage in 0-RTT data, this
how a client decides what TokenBindingMessage to send in 0-RTT data document also describes how a client decides what TokenBindingMessage
and how a server should interpret that message. to send in 0-RTT data and how a server should interpret that message.
If a client does not send any 0-RTT data, or if the server rejects 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, the client's 0-RTT data, then the client MUST use the 1-RTT exporter,
as defined in [I-D.ietf-tokbind-protocol]. as defined in [I-D.ietf-tokbind-protocol].
2.1. TokenBinding Signature Definition 2.1. TokenBinding Signature Definition
In [I-D.ietf-tokbind-protocol], the signature field of the In [I-D.ietf-tokbind-protocol], the signature field of the
TokenBinding struct is defined to be the signature of a TokenBinding struct is defined to be the signature of a
concatentation that includes the EKM value. Depending on the concatentation that includes the EKM value. Depending on the
circumstances, the exporter value in section 7.3.3 of circumstances, the exporter value in section 7.3.3 of
[I-D.ietf-tls-tls13] is computed using either exporter_secret or [I-D.ietf-tls-tls13] is computed using either exporter_secret or
early_exporter_secret as the Secret. The same Secret is used for the early_exporter_secret as the Secret.
entirety of the connection.
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. Selecting Which Exporter Secret to Use
The rules for a client choosing which exporter to use are as follows.
A client which is not sending any 0-RTT data on a connection MUST 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 the exporter defined in [I-D.ietf-tls-tls13] (using exporter_secret
as the Secret) for all TokenBindingMessages on that connection so as the Secret) for all TokenBindingMessages on that connection so
that it is compatible with [I-D.ietf-tokbind-protocol]. A client that it is compatible with [I-D.ietf-tokbind-protocol].
that sends a TokenBindingMessage in 0-RTT data must use the exporter
with early_exporter_secret as the Secret (the "0-RTT exporter") since When a client sends a TokenBindingMessage in 0-RTT data, it must use
exporter_secret is not defined at that time. A client that sends the early_exporter_secret. After the client receives an application-
0-RTT data which is not rejected by the server MUST use the 0-RTT layer response from the server, it must use the exporter_secret for
exporter for the rest of the connection. If the server rejects the all future token bindings on that connection. Requests sent after
client's 0-RTT data, then the client MUST use the exporter defined in the client's TLS Finished message, but before the client processes
[I-D.ietf-tls-tls13] (using exporter_secret as the Secret) for the any application-layer response from the server, may use either
remainder of the connection, as if no 0-RTT data had ever been sent. 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 the client
should re-send 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. Negotiating Token Binding
2.2.1. Negotiation TLS Extension 2.2.1. Negotiation TLS Extension
The behavior of the Token Binding negotiation TLS extension does not The behavior of the Token Binding negotiation TLS extension does not
change for a 0-RTT connection: the client and server should process change for a 0-RTT connection: the client and server should process
this extension the same way regardless of whether the client also this extension the same way regardless of whether the client also
sent the EarlyDataIndication extension. sent the EarlyDataIndication extension.
skipping to change at page 4, line 41 skipping to change at page 5, line 4
to replay the signature without having possession of the private key. to replay the signature without having possession of the private key.
To combat this attack, a server may implement some sort of replay To combat this attack, a server may implement some sort of replay
prevention, and indicate this to the client. A new TLS extension prevention, and indicate this to the client. A new TLS extension
"token_binding_replay_indication" is defined for the client to query "token_binding_replay_indication" is defined for the client to query
and server to indicate whether it has implemented a mechanism to and server to indicate whether it has implemented a mechanism to
prevent replay. prevent replay.
enum { enum {
token_binding_replay_indication(TBD), (65535) token_binding_replay_indication(TBD), (65535)
} ExtensionType; } ExtensionType;
When sent, this extension always has zero length. If a client wishes When sent, this extension always has zero length. If a client wishes
to know whether its peer is preventing replay of TokenBinding structs to know whether its peer is preventing replay of TokenBinding structs
across multiple connections, the client can include this extension in across multiple connections, the client can include this extension in
its ClientHello. Upon receiving this extension, the server must echo its ClientHello. Upon receiving this extension, the server must echo
it back if it is using such a mechanism (like those described in it back if it is using such a mechanism (like those described in
Section 6.3.1) to prevent replay. A client that only wishes to send Section 5.4.1) to prevent replay. A client that only wishes to send
0-RTT Token Binding if the server implements replay protection can 0-RTT Token Binding if the server implements replay protection can
send this extension on first connection establishment, and if the send this extension on first connection establishment, and if the
server doesn't send it back (but does support Token Binding) the server doesn't send it back (but does support Token Binding) the
client can choose to not send 0-RTT messages to that server. client can choose to not send 0-RTT messages to that server.
A client that wishes to use this extension should send it every time A client that wishes to use this extension should send it every time
it sends a "token_binding" [I-D.ietf-tokbind-negotiation] extension. it sends a "token_binding" [I-D.ietf-tokbind-negotiation] extension.
3. Implementation Challenges 3. Implementation Challenges
skipping to change at page 5, line 24 skipping to change at page 5, line 34
required rewriting a request, the client still has to handle the required rewriting a request, the client still has to handle the
server rejecting the 0-RTT data for other reasons. server rejecting the 0-RTT data for other reasons.
HTTP2 allows for requests to different domains to share the same TLS HTTP2 allows for requests to different domains to share the same TLS
connection if the SAN of the cert covers those domains. If connection if the SAN of the cert covers those domains. If
one.example.com supports 0-RTT and Token Binding, but two.example.com one.example.com supports 0-RTT and Token Binding, but two.example.com
only supports Token Binding as defined in only supports Token Binding as defined in
[I-D.ietf-tokbind-protocol], those servers cannot share a cert and [I-D.ietf-tokbind-protocol], those servers cannot share a cert and
use HTTP2. use HTTP2.
4. Alternatives Considered 4. IANA Considerations
4.1. Use Both 0-RTT and 1-RTT Exporters on Same Connection
The client could be required to use the 0-RTT EKM when the
TokenBindingMessage is sent in 0-RTT data, and the 1-RTT EKM when it
is sent in 1-RTT data. This requires that the abstraction of the TLS
layer visible to the application where it is handling Token Binding
exposes which phase the application data is being sent/received in.
An application could very easily have this detail abstracted away;
for example, the client might have a function like
"write_possibly_early" that will send data in 0-RTT the current
connection state permits it, and otherwise send data post-handshake.
A pathological client might send the first few bytes of an
application message in 0-RTT, but send the rest after the handshake
(including the TokenBindingMessage). The server's application layer
would have to track which bytes of the request were sent pre- and
post-handshake to know how to validate that TokenBindingMessage.
This constraint could be relaxed slightly. A ratcheting mechanism
could be used where the client uses the 0-RTT EKM while it thinks
that it's writing early data (even if it isn't writing early data),
and once it knows the handshake is finished, it uses the 1-RTT EKM.
Once the server sees a TokenBindingMessage using the 1-RTT EKM, the
server would no longer accept the 0-RTT EKM. In practice, this is
difficult to implement because multiple HTTP/2 streams can be
multiplexed on the same connection, requiring the ratchet to be
synchronized across the streams.
Relaxing this further where the server will always accept either the
0-RTT or 1-RTT EKM (but the client keeps the behavior as above) is
another possibility. This is more complicated than always using the
0-RTT exporter, and provides no additional security benefits (since
the server would have to accept a client only using the 0-RTT
exporter).
4.2. Don't Remember Key Parameter From Previous Connection
The proposed design uses the same Token Binding key parameter from
the previous connection, and the TLS extension must negotiate the
same key parameter as the previous connection. This mirrors how ALPN
is negotiated in TLS 1.3. Instead of remembering this parameter, the
client could put the in first entry of their key parameters list the
key type being used in 0-RTT, and allow the client and server to
potentially negotiate a new type to use once the handshake is
complete. This alternate gains a slight amount of key type agility
in exchange for implementation difficulty. Other variations of this
are also possible, for example requiring the server to reject early
data if it doesn't choose the first parameter, or requiring the
client to send only one key parameter.
4.3. Token Binding and 0-RTT Data Are Mutually Exclusive
If a TokenBindingMessage is never allowed in 0-RTT data, then no
changes are needed to the exporter or negotiation. A server that
wishes to support Token Binding must not create any NewSessionTicket
messages with the allow_early_data flag set. A client must not send
the token binding negotiation extension and the EarlyDataIndication
extension in the same ClientHello.
5. IANA Considerations
This document defines a new TLS extension This document defines a new TLS extension
"token_binding_replay_indication", which needs to be added to the "token_binding_replay_indication", which needs to be added to the
IANA "Transport Layer Security (TLS) Extensions" registry. IANA "Transport Layer Security (TLS) Extensions" registry.
6. Security Considerations This document defines a new Token Binding extension "early_exporter",
which needs to be added to the IANA "Token Binding Extensions"
registry.
5. Security Considerations
Token Binding messages that use the 0-RTT exporter have weaker Token Binding messages that use the 0-RTT exporter have weaker
security properties than with the [RFC5705] exporter. If either security properties than with the [RFC5705] exporter. If either
party of a connection using Token Binding does not wish to use 0-RTT 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 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 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 can choose to reject any 0-RTT data sent on a connection that
negotiated token binding. negotiated token binding.
0-RTT data in TLS 1.3 has weaker security properties than other kinds 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- of TLS data. Specifically, TLS 1.3 does not guarantee non-
replayability of data between connections. Token Binding has similar replayability of data between connections. Token Binding has similar
replayability issues when in 0-RTT data, but preventing replay of replayability issues when in 0-RTT data, but preventing replay of
Token Binding and preventing replay of 0-RTT data are two separate Token Binding and preventing replay of 0-RTT data are two separate
problems. Token Binding is not designed to prevent replay of 0-RTT problems. Token Binding is not designed to prevent replay of 0-RTT
data, although solutions for preventing the replay of Token Binding data, although solutions for preventing the replay of Token Binding
might also be applicable to 0-RTT data. might also be applicable to 0-RTT data.
6.1. Attacks on PSK-only Key Exchange and Token Binding 5.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 An attacker who possesses the PSK can eavesdrop on an existing
connection that uses that PSK to obtain a TokenBindingMessage that is connection that uses that PSK to obtain a TokenBindingMessage that is
valid on the connection and then hijack the connection to send valid on the connection and then hijack the connection to send
whatever attacker-controlled data it wishes. Because the regular whatever attacker-controlled data it wishes. Because the regular
exporter closes over the server random, this TokenBindingMessage is exporter closes over the server random, this TokenBindingMessage is
valid only for that connection. valid only for that connection.
If the attacker does the same thing with a pure-PSK connection and If the attacker does the same thing with a pure-PSK connection and
0-RTT Token Binding, the attacker can replay the original ClientHello 0-RTT Token Binding, the attacker can replay the original ClientHello
skipping to change at page 7, line 37 skipping to change at page 7, line 8
connections. The only way for a server to prevent this replay is to connections. The only way for a server to prevent this replay is to
prevent the client from ever repeating a client random in the prevent the client from ever repeating a client random in the
handshake. handshake.
If a server accepting connections with PSK-only key establishment is If a server accepting connections with PSK-only key establishment is
concerned about the threat of PSK theft and also implements Token concerned about the threat of PSK theft and also implements Token
Binding, then that server must either reject all 0-RTT token Binding, then that server must either reject all 0-RTT token
bindings, or implement some form of preventing reuse of a client bindings, or implement some form of preventing reuse of a client
random. random.
6.2. Exporter Replayability 5.3. Exporter Replayability
The exporter specified in [I-D.ietf-tokbind-protocol] is chosen so 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 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 are on the same TLS connection. This prevents an attacker who can
read the plaintext of a TokenBindingMessage sent on that connection read the plaintext of a TokenBindingMessage sent on that connection
from replaying that message on another connection (without also from replaying that message on another connection (without also
having the token binding private key). The 0-RTT exporter only having the token binding private key). The 0-RTT exporter only
covers the ClientHello and the PSK of the connection, so it does not covers the ClientHello and the PSK of the connection, so it does not
provide this guarantee. provide this guarantee.
skipping to change at page 8, line 22 skipping to change at page 7, line 42
This sort of replayability of a TokenBindingMessage is different than This sort of replayability of a TokenBindingMessage is different than
the replayability caveat of 0-RTT application data in TLS 1.3. A 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 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 any secrets of the client or server, but the application data that is
replayed is untouched. This replay is done by a more powerful replayed is untouched. This replay is done by a more powerful
attacker who is able to view the plaintext and then spoof a attacker who is able to view the plaintext and then spoof a
connection with the same parameters so that the replayed connection with the same parameters so that the replayed
TokenBindingMessage still validates when sent with different TokenBindingMessage still validates when sent with different
application data. application data.
6.3. Replay Mitigations 5.4. Replay Mitigations
This section presents multiple ways that a client or server can This section presents multiple ways that a client or server can
prevent the replay of a TokenBinding while still using Token Binding prevent the replay of a TokenBinding while still using Token Binding
with 0-RTT data. with 0-RTT data.
If a client or server implements a measure that prevents all replays, 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 then its peer does not also need to implement such a mitigation. A
client that is concerned about replay SHOULD implement replay a client that is concerned about replay SHOULD implement a replay
mitigation instead of relying solely on a signal from the server mitigation instead of relying solely on a signal from the server
through the replay indication extension. through the replay indication extension. Note that even with replay
mitigations, 0-RTT Token Binding is vulnerable to other attacks.
6.3.1. Server Mitigations 5.4.1. Server Mitigations
If a server uses a session cache instead of stateless tickets, it can 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. enforce that a PSK generated for resumption can only be used once.
If an attacker tries to replay 0-RTT data (with a If an attacker tries to replay 0-RTT data (with a
TokenBindingMessage), the server will reject it because the PSK was TokenBindingMessage), the server will reject it because the PSK was
already used. already used.
Preventing all replay of 0-RTT data is not necessary to prevent Preventing all replay of 0-RTT data is not necessary to prevent
replay of a TokenBinding. A server could implement a mechanism to replay of a TokenBinding. A server could implement a mechanism to
prevent a particular TokenBinding from being presented on more than prevent a particular TokenBinding from being presented on more than
one connection. In cases where a server's TLS termination and one connection. In cases where a server's TLS termination and
application layer processing happen in different locations, this application layer processing happen in different locations, this
option might be easier to implement, especially when not all requests option might be easier to implement, especially when not all requests
have bound tokens. This processing can also take advantage of the have bound tokens. This processing can also take advantage of the
structure of the bound token, e.g. a token that identifies which user 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 is making a request could shard its store of which TokenBindings have
been seen based on the user ID. been seen based on the user ID.
A server can prevent some, but not all, 0-RTT data replay with a 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 tight time window for the ticket age that it will accept. See
Section 6.4 for more details. Section 5.5 for more details.
6.3.2. Client Mitigations 5.4.2. Client Mitigations
A client cannot prevent a sufficiently motivated attacker from A client cannot prevent a sufficiently motivated attacker from
replaying a TokenBinding, but it can make it so difficult to replay replaying a TokenBinding, but it can make it so difficult to replay
the TokenBinding that it is easier for the attacker to steal the the TokenBinding that it is easier for the attacker to steal the
Token Binding key directly. If the client secures the resumption Token Binding key directly. If the client secures the resumption
secret with the same level of protection as the Token Binding key, 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 then the client has made it not worth the effort of the attacker to
attempt to replay a TokenBinding. Ideally the resumption secret (and attempt to replay a TokenBinding. Ideally the resumption secret (and
Token Binding key) are protected strongly and virtually non- Token Binding key) are protected strongly and virtually non-
exportable. exportable.
6.4. Early Data Ticket Age Window 5.5. Early Data Ticket Age Window
When an attacker with control of the PSK secret replays a When an attacker with control of the PSK secret replays a
TokenBindingMessage, it has to use the same ClientHello that the TokenBindingMessage, it has to use the same ClientHello that the
client used. The ClientHello includes an "obfuscated_ticket_age" in client used. The ClientHello includes an "obfuscated_ticket_age" in
its EarlyDataIndication extension, which the server can use to narrow its EarlyDataIndication extension, which the server can use to narrow
the window in which that ClientHello will be accepted. Even if a PSK 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 is valid for a week, the server will only accept that particular
ClientHello for a smaller time window based on the ticket age. A ClientHello for a smaller time window based on the ticket age. A
server should make their acceptance window for this value as small as server should make their acceptance window for this value as small as
practical to limit an attacker's ability to replay a ClientHello and practical to limit an attacker's ability to replay a ClientHello and
send new application data with the stolen TokenBindingMessage. send new application data with the stolen TokenBindingMessage.
6.5. Lack of Freshness 6. Acknowledgements
The 0-RTT exporter value does not contain anything that the client
cannot precompute before connecting to the server. Therefore, an
attacker could have a client generate but not send a series of
messages to take particular actions, and then selectively send one of
those messages at a later date. If this attack includes deleting the
resumption secret from the client, then these latent attacker-held
messages will be the only ones to use that resumption secret and
replay protections do not prevent this attack.
7. Acknowledgements
The author would like to thank David Benjamin, Steven Valdez, Bill The author would like to thank David Benjamin, Steven Valdez, Bill
Cox, and Andrei Popov for their feedback and suggestions. Cox, and Andrei Popov for their feedback and suggestions.
8. Normative References 7. Normative References
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress), Version 1.3", draft-ietf-tls-tls13-19 (work in progress),
October 2016. March 2017.
[I-D.ietf-tokbind-negotiation] [I-D.ietf-tokbind-negotiation]
Popov, A., Nystrom, M., Balfanz, D., and A. Langley, Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
"Transport Layer Security (TLS) Extension for Token "Transport Layer Security (TLS) Extension for Token
Binding Protocol Negotiation", draft-ietf-tokbind- Binding Protocol Negotiation", draft-ietf-tokbind-
negotiation-05 (work in progress), September 2016. negotiation-07 (work in progress), February 2017.
[I-D.ietf-tokbind-protocol] [I-D.ietf-tokbind-protocol]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "The Token Binding Protocol Version 1.0", draft- Hodges, "The Token Binding Protocol Version 1.0", draft-
ietf-tokbind-protocol-10 (work in progress), September ietf-tokbind-protocol-13 (work in progress), February
2016. 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>. March 2010, <http://www.rfc-editor.org/info/rfc5705>.
 End of changes. 29 change blocks. 
130 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/