Subject: [Unbearable] Token Binding for 0-RTT connections

From: Nick Harper <[email-masked]>
Date: Tue, 13 Sep 2016 17:05:30 -0700

Hi,
I just uploaded
https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-00, which is
an attempt to describe how to do Token Binding on 0-RTT TLS 1.3
connections. What do people think of it?
-Nick

---

From: Nick Harper <[email-masked]>
Date: Mon, 19 Sep 2016 14:59:16 -0700

I'd like to get more feedback from the Token Binding WG on this. Here's a
brief summary of the draft:

TLS 1.3 has a mode that allows the client to send application data
immediately after its first handshake message (this application data is
"early data" or "0-RTT data"), before waiting for a response from the
server. There is no exporter value for the connection at this point, since
it depends on the crypto handshake finishing. This means that a
TokenBindingMessage can't be sent in 0-RTT data as currently defined. My
draft solves this problem in two parts. The first part is to define an
exporter that can be used when generating 0-RTT data, and the second part
is to describe how negotiation works with 0-RTT connections and which
exporter should be used when. Specifically, it requires that the client
re-use the same TB key param in 0-RTT data as was used in the original
connection, and it requires that if a client sends 0-RTT data (and the
server accepts it) that the client continue to use the 0-RTT exporter to
generate the rest of their TokenBindingMessages.

I have 2 questions:
1. Is this working group interested in solving this problem (making Token
Binding work on 0-RTT connections)?
2. Does this seem like a reasonable approach?

On Tue, Sep 13, 2016 at 5:05 PM, Nick Harper <[email-masked]> wrote:

> Hi,
> I just uploaded https://tools.ietf.org/html/draft-nharper-0-rtt-
> token-binding-00, which is an attempt to describe how to do Token Binding
> on 0-RTT TLS 1.3 connections. What do people think of it?
> -Nick
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 19 Sep 2016 22:48:20 +0000

Hi Nick,

1.       I’m definitely interested.

2.       The general approach seems OK, based on TLS 1.3 as we know it right now. The bigger problem of replay is not adequately addressed, IMHO. But then it’s a -00 draft☺.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, September 19, 2016 2:59 PM
To: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

I'd like to get more feedback from the Token Binding WG on this. Here's a brief summary of the draft:

TLS 1.3 has a mode that allows the client to send application data immediately after its first handshake message (this application data is "early data" or "0-RTT data"), before waiting for a response from the server. There is no exporter value for the connection at this point, since it depends on the crypto handshake finishing. This means that a TokenBindingMessage can't be sent in 0-RTT data as currently defined. My draft solves this problem in two parts. The first part is to define an exporter that can be used when generating 0-RTT data, and the second part is to describe how negotiation works with 0-RTT connections and which exporter should be used when. Specifically, it requires that the client re-use the same TB key param in 0-RTT data as was used in the original connection, and it requires that if a client sends 0-RTT data (and the server accepts it) that the client continue to use the 0-RTT exporter to generate the rest of their TokenBindingMessages.

I have 2 questions:
1. Is this working group interested in solving this problem (making Token Binding work on 0-RTT connections)?
2. Does this seem like a reasonable approach?

On Tue, Sep 13, 2016 at 5:05 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I just uploaded https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-00, which is an attempt to describe how to do Token Binding on 0-RTT TLS 1.3 connections. What do people think of it?
-Nick

---

From: Andrei Popov <[email-masked]>
Date: Mon, 19 Sep 2016 23:02:45 +0000

P.S. It may be a good idea to present this in Seoul.

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Monday, September 19, 2016 3:48 PM
To: Nick Harper <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

Hi Nick,

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Monday, September 19, 2016 2:59 PM
To: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

I have 2 questions:

---

From: Nick Harper <[email-masked]>
Date: Mon, 19 Sep 2016 17:20:52 -0700

Hi Andrei,
I was wondering if you could elaborate on your concerns around
replayability - do you see areas in the design that could be improved to
limit replays, or would you like to see more guidance for client vendors
and server operators on how to limit replays? I tried to address it in
section 5.1, but it's quite likely I missed some things. (Bill Cox recently
brought up the idea about applying replay protection to the Token Binding
headers themselves, which is something that this draft does not cover.)

I'd be glad to present this in Seoul if people are interested.
-Nick

On Mon, Sep 19, 2016 at 4:02 PM, Andrei Popov <[email-masked]>
wrote:

> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Andrei
> Popov
> *Sent:* Monday, September 19, 2016 3:48 PM
> *To:* Nick Harper <[email-masked]>; IETF Tokbind WG <
> [email-masked]>
> *Subject:* Re: [Unbearable] Token Binding for 0-RTT connections
>
>
>
> Hi Nick,
>
>
>
> 2.       The general approach seems OK, based on TLS 1.3 as we know it
> right now. The bigger problem of replay is not adequately addressed, IMHO.
> But then it’s a -00 draftJ.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Nick Harper
> *Sent:* Monday, September 19, 2016 2:59 PM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] Token Binding for 0-RTT connections
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 20 Sep 2016 00:43:30 +0000

Ø  do you see areas in the design that could be improved to limit replays, or would you like to see more guidance for client vendors and server operators on how to limit replays?
There needs to be normative language that eliminates replays. Replayable TB is useless.

Ø  Bill Cox recently brought up the idea about applying replay protection to the Token Binding headers themselves, which is something that this draft does not cover.
This is one of the options. The other option we know of is protecting resumption state.  I think it’s not enough to discuss these options; replay prevention should be a requirement.

Cheers,

Andrei

From: Nick Harper [mailto:[email-masked]]
Sent: Monday, September 19, 2016 5:21 PM
To: Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

Hi Andrei,
I was wondering if you could elaborate on your concerns around replayability - do you see areas in the design that could be improved to limit replays, or would you like to see more guidance for client vendors and server operators on how to limit replays? I tried to address it in section 5.1, but it's quite likely I missed some things. (Bill Cox recently brought up the idea about applying replay protection to the Token Binding headers themselves, which is something that this draft does not cover.)

On Mon, Sep 19, 2016 at 4:02 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
P.S. It may be a good idea to present this in Seoul.

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrei Popov
Sent: Monday, September 19, 2016 3:48 PM
To: Nick Harper <[email-masked]<mailto:[email-masked]>>; IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

Hi Nick,

Cheers,

Andrei

I have 2 questions:

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 11:03:06 -0700

On Mon, Sep 19, 2016 at 5:43 PM, Andrei Popov <[email-masked]>
wrote:

> Replayable TB is useless.
>
I think that depends on what threat model you're considering for Token
Binding. No replayability of TokenBindingMessages is ideal, but even if
there are some limited cases where TB is replayable, there still is value
in that. I think we both agree that if the client's resumption secret is
protected the same as the TB key, then we achieve the same level of
security with 0-RTT token binding as "normal" token binding. Note though
that this doesn't do anything to prevent replay of a TB message. An
attacker who gets access to the resumption secret could sniff a TB message
and replay it even if the resumption secret is protected the same as the TB
key. The reason why this is considered acceptable is because if the
attacker has the resumption secret, they could also use the TB key directly
to generate a new TB message.

I think there are multiple options both client-side and server-side that
can be taken to prevent replay (or make replay require access to the TB
key), using the exporter and negotiation in my draft. For client-side
options, the client could send an extension in the TB message that is
basically a bit saying "the client is preventing replay" (like RFC 3514),
although this is problematic because extensions aren't signed, so the
attacker can trivially add in that extension. (Changing the signature to
close over extensions could solve this, or having this specific extension
include a signature could solve it, but that seems like a waste of bytes.)
A server can't indicate that it's taking some sort of measure to prevent
replay (like using a session cache instead of generating stateless
tickets), but if a server cares about replay and a client doesn't, then
that's still fine for the server.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Sep 2016 18:37:24 +0000

Ø  I think we both agree that if the client's resumption secret is protected the same as the TB key, then we achieve the same level of security with 0-RTT token binding as "normal" token binding. Note though that this doesn't do anything to prevent replay of a TB message.
I guess when I say “resumption secret is protected the same as the TB key”, I mean that they are both protected strongly, and are both virtually non-exportable☺. If they are both protected equally weakly, and are exportable, then this kind of TB is a waste of CPU cycles.

Ø  For client-side options, the client could send an extension in the TB message that is basically a bit saying "the client is preventing replay"…
You’re talking about indications in the protocol, which may be useful, but the issue I raised with the I-D is different. I think the I-D needs to have normative language requiring replay mitigations (non-exportable resumption secret, server-side replay prevention etc.) These cannot merely be recommendations. And yes, we can separately discuss whether or how these mitigations are indicated.

Ø  …although this is problematic because extensions aren't signed, so the attacker can trivially add in that extension.
Ideally, the client would present cryptographic proof of the keys being strongly protected. This proof can be carried in a TB extension. This is actually the primary use-case I had for TB extensions.

Cheers,

Andrei

Sent: Wednesday, September 21, 2016 11:03 AM

On Mon, Sep 19, 2016 at 5:43 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Replayable TB is useless.
I think that depends on what threat model you're considering for Token Binding. No replayability of TokenBindingMessages is ideal, but even if there are some limited cases where TB is replayable, there still is value in that. I think we both agree that if the client's resumption secret is protected the same as the TB key, then we achieve the same level of security with 0-RTT token binding as "normal" token binding. Note though that this doesn't do anything to prevent replay of a TB message. An attacker who gets access to the resumption secret could sniff a TB message and replay it even if the resumption secret is protected the same as the TB key. The reason why this is considered acceptable is because if the attacker has the resumption secret, they could also use the TB key directly to generate a new TB message.

I think there are multiple options both client-side and server-side that can be taken to prevent replay (or make replay require access to the TB key), using the exporter and negotiation in my draft. For client-side options, the client could send an extension in the TB message that is basically a bit saying "the client is preventing replay" (like RFC 3514), although this is problematic because extensions aren't signed, so the attacker can trivially add in that extension. (Changing the signature to close over extensions could solve this, or having this specific extension include a signature could solve it, but that seems like a waste of bytes.) A server can't indicate that it's taking some sort of measure to prevent replay (like using a session cache instead of generating stateless tickets), but if a server cares about replay and a client doesn't, then that's still fine for the server.

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 14:36:41 -0700

On Wed, Sep 21, 2016 at 11:37 AM, Andrei Popov <[email-masked]>
wrote:

> Ø  I think we both agree that if the client's resumption secret is
> that this doesn't do anything to prevent replay of a TB message.
>
> I guess when I say “resumption secret is protected the same as the TB
> key”, I mean that they are both protected strongly, and are both virtually
> non-exportableJ.
>

 Even if they are both protected strongly (e.g. backed in hardware with the
private key being non-exportable), an attacker running with the same
privileges as the browser can use the same mechanism as the browser to use
(but not export) the keys to either sniff a TB message from a connection
and then replay it on a connection resumed with the same secret, or
generate new TB messages for new connections. My point here is that
protecting the resumption secret strongly is sufficient protection, even
though it doesn't prevent replay. Thus, preventing all replay sounds like
too strong of a requirement.

If they are both protected equally weakly, and are exportable, then this
> kind of TB is a waste of CPU cycles.
>

Whether or not this kind of TB is a waste depends on your threat model.
Chrome does not protect TB keys - they're in a sqlite database in the
user's profile. This form of TB (where the keys aren't in hardware) still
provides protection against some forms of attacks (like XSS, cookie
injection attacks, or even malicious browser extensions). If the attacker
in your threat model does not have the same (or higher) privileges as the
browser, then there's no need to put the keys in hardware. If the attacker
does have the same privileges as the browser, then the attacker can use
whatever TB store the browser uses (including one that has TB keys
non-extractable in hardware) as a signing oracle.

This is why I'm asking what the threat model is - what kinds of attacks is
Token Binding being designed to protect against (and succeeding at
protecting against)? What is the minimum level of attack that Token Binding
needs to protect against for this Working Group to consider?

If the threat model is an attacker is running code on the victim's machine
with the same privilege as the client software (browser), and we want to
prevent the attacker from ever being able to exercise a bound token from
the victim, then Token Binding does not provide this protection. So long as
the attacker is still present on the victim's machine, the attacker has
access to an oracle to generate the signature for a TokenBinding for any
connection. This is the case even if the keys are in hardware, and even if
there is attestation.

Suppose we relax that constraint and instead want to protect against an
attacker trying to get persistent use of a bound token. In this case, the
attacker could replace the client's hardware-backed key store with an
attacker-controlled key store. When the user obtains tokens, they get bound
to the keys in the attacker-controlled key store, and the attacker can
exfiltrate both the tokens and the keys they are bound to. Token Binding
with key attestation appears to solve this problem, but only if the server
requires attestation. Key attestation isn't defined as part of Token
Binding (though it might be in an extension), and has privacy implications.

I realize that the security properties of Token Binding on 0-RTT
connections won't be the same as on TLS 1.2 connections. I think we need a
design that meets or exceeds the minimum threat model that this Working
Group is designing for. Designing it to allow clients and servers to impose
more stringent checks (similar to using an extension for attestation in the
existing drafts) is reasonable, so long as that isn't a requirement. A
client or server can always choose to meet at least the same level of
security as TB over TLS 1.2 by rejecting 0-RTT data with TB.

---

From: Bill Cox <[email-masked]>
Date: Wed, 21 Sep 2016 14:37:57 -0700

On Wed, Sep 21, 2016 at 11:03 AM, Nick Harper <[email-masked]> wrote:

> in that.

For any 0-RTT, we cannot do a real proof-of-possession, so the best we can
do is emulate one.  The two properties I can think of that define a "real"
PoP are:

1) uniqueness
2) freshness

Uniqueness can be ensured server-side (assuming we don't really want to let
the client implement RFC 3514).  Freshness is tougher.  Consider this
malware attack:

The attacker steals your ticket and resumption secret, then deletes them
from your computer.  (S)he also accesses the TB signing oracle to generate
a TB header for a future 0-RTT resume.  The attacker leaves your computer
and then at a later point in time resumes the connection and keeps it alive
long-term.

This attack succeeds even if the user becomes aware of the problem.  The
user can reinstall their OS and remove the TB keys physically from the
computer, and the attack still works after these steps are taken.

So... any improvement we could make in freshness would be nice.  Here's
today's dumb idea (not a serious proposal, but better than RFC 3514): we
could sign the time.  There is a new tool that aims to distribute time
securely <https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md>.
A signed time from a trusted time server could be included in the TB signed
data.  Servers would simply reject TB headers that are too old.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Sep 2016 21:52:26 +0000

Ø  This is why I'm asking what the threat model is - what kinds of attacks is Token Binding being designed to protect against (and succeeding at protecting against)?
Per Tokbind WG charter: “Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client.”

Ø  Suppose we relax that constraint and instead want to protect against an attacker trying to get persistent use of a bound token.
This appears to be the minimum bar, per charter.

Cheers,

Andrei

Sent: Wednesday, September 21, 2016 2:37 PM

On Wed, Sep 21, 2016 at 11:37 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  I think we both agree that if the client's resumption secret is protected the same as the TB key, then we achieve the same level of security with 0-RTT token binding as "normal" token binding. Note though that this doesn't do anything to prevent replay of a TB message.
I guess when I say “resumption secret is protected the same as the TB key”, I mean that they are both protected strongly, and are both virtually non-exportable☺.

 Even if they are both protected strongly (e.g. backed in hardware with the private key being non-exportable), an attacker running with the same privileges as the browser can use the same mechanism as the browser to use (but not export) the keys to either sniff a TB message from a connection and then replay it on a connection resumed with the same secret, or generate new TB messages for new connections. My point here is that protecting the resumption secret strongly is sufficient protection, even though it doesn't prevent replay. Thus, preventing all replay sounds like too strong of a requirement.

If they are both protected equally weakly, and are exportable, then this kind of TB is a waste of CPU cycles.

Whether or not this kind of TB is a waste depends on your threat model. Chrome does not protect TB keys - they're in a sqlite database in the user's profile. This form of TB (where the keys aren't in hardware) still provides protection against some forms of attacks (like XSS, cookie injection attacks, or even malicious browser extensions). If the attacker in your threat model does not have the same (or higher) privileges as the browser, then there's no need to put the keys in hardware. If the attacker does have the same privileges as the browser, then the attacker can use whatever TB store the browser uses (including one that has TB keys non-extractable in hardware) as a signing oracle.

This is why I'm asking what the threat model is - what kinds of attacks is Token Binding being designed to protect against (and succeeding at protecting against)? What is the minimum level of attack that Token Binding needs to protect against for this Working Group to consider?

If the threat model is an attacker is running code on the victim's machine with the same privilege as the client software (browser), and we want to prevent the attacker from ever being able to exercise a bound token from the victim, then Token Binding does not provide this protection. So long as the attacker is still present on the victim's machine, the attacker has access to an oracle to generate the signature for a TokenBinding for any connection. This is the case even if the keys are in hardware, and even if there is attestation.

Suppose we relax that constraint and instead want to protect against an attacker trying to get persistent use of a bound token. In this case, the attacker could replace the client's hardware-backed key store with an attacker-controlled key store. When the user obtains tokens, they get bound to the keys in the attacker-controlled key store, and the attacker can exfiltrate both the tokens and the keys they are bound to. Token Binding with key attestation appears to solve this problem, but only if the server requires attestation. Key attestation isn't defined as part of Token Binding (though it might be in an extension), and has privacy implications.

I realize that the security properties of Token Binding on 0-RTT connections won't be the same as on TLS 1.2 connections. I think we need a design that meets or exceeds the minimum threat model that this Working Group is designing for. Designing it to allow clients and servers to impose more stringent checks (similar to using an extension for attestation in the existing drafts) is reasonable, so long as that isn't a requirement. A client or server can always choose to meet at least the same level of security as TB over TLS 1.2 by rejecting 0-RTT data with TB.

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 15:00:53 -0700

On Wed, Sep 21, 2016 at 2:52 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  This is why I'm asking what the threat model is - what kinds of
> attacks is Token Binding being designed to protect against (and succeeding
> at protecting against)?
>
> Per Tokbind WG charter: “Attackers export bearer tokens from client
> machines or from compromised network connections, present these bearer
> tokens to Web services, and impersonate authenticated users. Token Binding
> enables defense against such attacks by cryptographically binding security
> tokens to a secret held by the client.”
>

It enables defense against such attacks, it doesn't prevent them. The
HttpOnly cookie flag also provides defense against cookie theft attacks,
but does not prevent all classes of them.

>
>
> Ø  Suppose we relax that constraint and instead want to protect against
> an attacker trying to get persistent use of a bound token.
>

If the minimum bar is at least that an attacker running malware on a
victim's machine (at at least the same privilege level as the browser) is
not able to impersonate the user in a single request using a bound token,
then Token Binding, as defined in draft-ietf-tokbind-*, does not meet this
bar.

>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Nick Harper [mailto:[email-masked]]
> *Sent:* Wednesday, September 21, 2016 2:37 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* IETF Tokbind WG <[email-masked]>
>  Even if they are both protected strongly (e.g. backed in hardware with
> the private key being non-exportable), an attacker running with the same

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Sep 2016 22:17:47 +0000

Ø  If the minimum bar is at least that an attacker running malware on a victim's machine (at at least the same privilege level as the browser) is not able to impersonate the user in a single request using a bound token, then Token Binding, as defined in draft-ietf-tokbind-*, does not meet this bar.
I think the minimum bar is to prevent the attacker from exporting a token and successfully using it from another machine. And this is what the charter seems to be saying, at least that’s my reading of it.

Sent: Wednesday, September 21, 2016 3:01 PM

On Wed, Sep 21, 2016 at 2:52 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  This is why I'm asking what the threat model is - what kinds of attacks is Token Binding being designed to protect against (and succeeding at protecting against)?

It enables defense against such attacks, it doesn't prevent them. The HttpOnly cookie flag also provides defense against cookie theft attacks, but does not prevent all classes of them.

>  Suppose we relax that constraint and instead want to protect against an attacker trying to get persistent use of a bound token.

If the minimum bar is at least that an attacker running malware on a victim's machine (at at least the same privilege level as the browser) is not able to impersonate the user in a single request using a bound token, then Token Binding, as defined in draft-ietf-tokbind-*, does not meet this bar.

Cheers,

Andrei

From: Nick Harper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 21, 2016 2:37 PM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 15:27:59 -0700

An attacker running malware on the victim's machine can export a token
(bound with Token Binding) and successfully use it on another machine. The
attacker needs a connection to the victim's machine to use it as a signing
oracle, but the attacker can otherwise establish the connection from the
other machine.

On Wed, Sep 21, 2016 at 3:17 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  If the minimum bar is at least that an attacker running malware on a
> I think the minimum bar is to prevent the attacker from exporting a token
> and successfully using it from another machine. And this is what the
> charter seems to be saying, at least that’s my reading of it.
>
>
>
> *Sent:* Wednesday, September 21, 2016 3:01 PM
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Sep 2016 22:41:00 +0000

Correct, if the attacker has continuous access to the client machine, and is able to use it as a remote signing oracle, then the attacker can successfully export and use the bound token. Or they could keep running on the client machine without all that trouble. In other words, TB is not protecting the tokens on a machine that is continuously compromised, while it remains compromised.

Sent: Wednesday, September 21, 2016 3:28 PM

An attacker running malware on the victim's machine can export a token (bound with Token Binding) and successfully use it on another machine. The attacker needs a connection to the victim's machine to use it as a signing oracle, but the attacker can otherwise establish the connection from the other machine.

Cheers,

Andrei

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 15:45:39 -0700

If the client machine has low bandwidth, the attacker might choose to use
it as a signing oracle. My point is that the minimum bar can't be
"prevent[ing] the attacker from exporting a token and successfully using it
from another machine", since that's an example of not meeting that bar.

That seems to be one way of reading what the charter says, but the charter
only says "Token Binding enables defense against such attacks", not that it
prevents such attacks. I think an equally valid reading of the charter
would be that "Token Binding makes it harder to carry out such attacks than
if the tokens were not bound", and using TB with the keys in plaintext on
the client's filesystem meets that bar.

On Wed, Sep 21, 2016 at 3:41 PM, Andrei Popov <[email-masked]>
wrote:

> Correct, if the attacker has continuous access to the client machine, and
> is able to use it as a remote signing oracle, then the attacker can
> successfully export and use the bound token. Or they could keep running on
> the client machine without all that trouble. In other words, TB is not
> protecting the tokens on a machine that is continuously compromised, while
> it remains compromised.
>
>
>
> *Sent:* Wednesday, September 21, 2016 3:28 PM
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Sep 2016 23:38:55 +0000

Are you saying that it’s OK for TB to offer weaker security guarantees when used with TLS 1.3 0-RTT, and therefore we need not require the use of additional replay mitigations (strong protection of resumption state, server-side replay prevention measures, etc.)?

Sent: Wednesday, September 21, 2016 3:46 PM

If the client machine has low bandwidth, the attacker might choose to use it as a signing oracle. My point is that the minimum bar can't be "prevent[ing] the attacker from exporting a token and successfully using it from another machine", since that's an example of not meeting that bar.

That seems to be one way of reading what the charter says, but the charter only says "Token Binding enables defense against such attacks", not that it prevents such attacks. I think an equally valid reading of the charter would be that "Token Binding makes it harder to carry out such attacks than if the tokens were not bound", and using TB with the keys in plaintext on the client's filesystem meets that bar.

On Wed, Sep 21, 2016 at 3:41 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Correct, if the attacker has continuous access to the client machine, and is able to use it as a remote signing oracle, then the attacker can successfully export and use the bound token. Or they could keep running on the client machine without all that trouble. In other words, TB is not protecting the tokens on a machine that is continuously compromised, while it remains compromised.

Cheers,

Andrei

---

From: Nick Harper <[email-masked]>
Date: Wed, 21 Sep 2016 17:24:43 -0700

I'm saying that the security guarantees of TB when used with TLS 1.3 0-RTT
are likely not going to be the same as with TLS 1.2. I think that the idea
that replay must be prevented is wrong: strong protection of resumption
state doesn't prevent replay, it just means that an attacker capable of
replaying a TB can just as easily get the key, and Bill Cox's example is
one where no replay happens yet the TB is still used by the attacker
(meaning that something else is needed besides replay protection).

The idea that replay must be prevented presumably comes from some implicit
assumptions about what attacks/threats Token Binding is solving. I'm trying
to get that threat model to be explicit, and make sure that it is one that
the current drafts actually solve, so that I can design TB with 0-RTT
against that threat model.

I think it's also OK for TB with 0-RTT to offer varying levels of security
depending on how the client and server choose to implement it, just like
how TB (in the current ietf-tokbind drafts) offers different levels of
security depending on whether or not TB keys are backed in hardware. I'm
not saying we shouldn't consider any mitigations like storing resumption
state just as strongly as the TB keys, or servers using session caches
instead of stateless tickets.

On Wed, Sep 21, 2016 at 4:38 PM, Andrei Popov <[email-masked]>
wrote:

> Are you saying that it’s OK for TB to offer weaker security guarantees
> when used with TLS 1.3 0-RTT, and therefore we need not require the use of
> additional replay mitigations (strong protection of resumption state,
> server-side replay prevention measures, etc.)?
>
>
>
> *Sent:* Wednesday, September 21, 2016 3:46 PM
>

---

From: Bill Cox <[email-masked]>
Date: Wed, 21 Sep 2016 18:10:01 -0700

> (meaning that something else is needed besides replay protection).

Yep.  We need freshness, in addition to uniqueness, to be similar to TLS
1.2 (though still not exactly the same).  We might want to brain-storm on
the unbearable list about how we might improve freshness.  If there were a
global signed time signal sent to everyone every few seconds, we could sign
that, and get close to a full PoP, but this is a huge add-on to an
otherwise relatively simple RFC proposal.

> against that threat model.

Successful replay violates the TB guarantee, and I think that's where the
idea that it must be prevented comes from.  Many of the  "new and exciting"
attacks against 0-RTT on the TLS 1.3 list are due to no replay protection
for 0-RTT data.

If we provide 100% replay protection of TB headers in gaia, there will be a
significant side-benefit of preventing the simplest 0-RTT application
request replay attacks.  The more complex attacks involving multiple data
centers still can succeed for a 1-time replay, but the infinite-replay
attack is still foiled, and there are simple 1-time replay attacks against
TLS 1.2 in any case.  I'm still not convinced it is worth the effort,
though.

> instead of stateless tickets.

Agreed.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Sep 2016 18:12:29 +0000

My feedback for draft-nharper-0-rtt-token-binding-00 is that merely discussing 0-RTT TB’s weaker security properties in the security considerations is not sufficient.

I think it would make sense to define the mitigation options we’ve come up with so far, and some way to indicate the protection(s) that are in place, so that a peer can make an informed decision whether to use 0-RTT TB or not.

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, September 21, 2016 6:10 PM
To: Nick Harper <[email-masked]>
Cc: Andrei Popov <[email-masked]>; IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Token Binding for 0-RTT connections

On Wed, Sep 21, 2016 at 5:24 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> wrote:
I'm saying that the security guarantees of TB when used with TLS 1.3 0-RTT are likely not going to be the same as with TLS 1.2. I think that the idea that replay must be prevented is wrong: strong protection of resumption state doesn't prevent replay, it just means that an attacker capable of replaying a TB can just as easily get the key, and Bill Cox's example is one where no replay happens yet the TB is still used by the attacker (meaning that something else is needed besides replay protection).

Yep.  We need freshness, in addition to uniqueness, to be similar to TLS 1.2 (though still not exactly the same).  We might want to brain-storm on the unbearable list about how we might improve freshness.  If there were a global signed time signal sent to everyone every few seconds, we could sign that, and get close to a full PoP, but this is a huge add-on to an otherwise relatively simple RFC proposal.

The idea that replay must be prevented presumably comes from some implicit assumptions about what attacks/threats Token Binding is solving. I'm trying to get that threat model to be explicit, and make sure that it is one that the current drafts actually solve, so that I can design TB with 0-RTT against that threat model.

Successful replay violates the TB guarantee, and I think that's where the idea that it must be prevented comes from.  Many of the  "new and exciting" attacks against 0-RTT on the TLS 1.3 list are due to no replay protection for 0-RTT data.

If we provide 100% replay protection of TB headers in gaia, there will be a significant side-benefit of preventing the simplest 0-RTT application request replay attacks.  The more complex attacks involving multiple data centers still can succeed for a 1-time replay, but the infinite-replay attack is still foiled, and there are simple 1-time replay attacks against TLS 1.2 in any case.  I'm still not convinced it is worth the effort, though.

I think it's also OK for TB with 0-RTT to offer varying levels of security depending on how the client and server choose to implement it, just like how TB (in the current ietf-tokbind drafts) offers different levels of security depending on whether or not TB keys are backed in hardware. I'm not saying we shouldn't consider any mitigations like storing resumption state just as strongly as the TB keys, or servers using session caches instead of stateless tickets.

Agreed.

Bill

---

From: Bill Cox <[email-masked]>
Date: Thu, 22 Sep 2016 11:51:01 -0700

On Thu, Sep 22, 2016 at 11:12 AM, Andrei Popov <[email-masked]>
wrote:

> My feedback for draft-nharper-0-rtt-token-binding-00 is that merely
> discussing 0-RTT TB’s weaker security properties in the security
> considerations is not sufficient.
>
>
>
> I think it would make sense to define the mitigation options we’ve come up
> with so far, and some way to indicate the protection(s) that are in place,
> so that a peer can make an informed decision whether to use 0-RTT TB or not.
>

I agree.  I also would prefer a mitigation techniques for 0-RTT security
concerns section in the TLS 1.3 doc, but that did not make it in.  This is
pretty similar stuff: we need anti-replay on the server, key protection on
the client, and somehow we need to ensure signatures are fresh.  When we
combine all that, I think we would have security very close to TB over
1-RTT resumption.