Subject: [Unbearable] Switching exporters for 0-RTT Token Binding

From: Nick Harper <[email-masked]>
Date: Tue, 18 Apr 2017 15:24:40 -0700

One of the issues raised in Chicago around 0-RTT Token Binding is
whether or not to switch from the 0-RTT exporter to the normal
exporter, and I'd like to get some feedback from the Working Group on
this.

The two options I'm considering are as follows:
1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted.
2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT.
The client switches to using the normal exporter soon after the
handshake finishes, but it may send some Token Binding messages
post-handshake using the 0-RTT exporter.
In both cases, if the server rejects 0-RTT data, the client uses the
normal exporter (i.e. the client behaves the same as in TBPROTO).

I'm currently leaning towards option 1. Below are my arguments for
each option. I'm interested in hearing additional arguments
for/against each option and what people's preference is. I'm
particularly interested in the opinion of server operators who would
be implementing this.

For option 1:
Option 1 is simple to implement. No extension (or other mechanism) is
needed in the TokenBinding struct to indicate which exporter was used
to avoid the server needing to do trial verification. Code paths are
simpler on both the client and server when the exporter value remains
constant for the whole connection.

When a server is choosing whether to accept or reject 0-RTT data, it
cannot base this decision on the content of the 0-RTT data, which
means that a server that chooses to accept a 0-RTT Token Binding makes
that decision without knowing what the message contents are. It
follows that said server finds the security properties of 0-RTT Token
Binding acceptable on any request received in 0-RTT. If a server finds
the security properties of 0-RTT Token Binding acceptable on a request
when it is received in 0-RTT data, then it would only be logical for
it to find those security properties acceptable when that request is
not in 0-RTT data (i.e. post-handshake), and since that server will
accept any message (with 0-RTT Token Binding) in 0-RTT data (because
it can't choose whether or not to do 0-RTT based on message contents),
there would be no case where the server would only accept the normal
exporter.

For option 2:
A server might have some requests where it is fine with the security
properties of 0-RTT Token Binding, and others where it wants the full
protection of the (normal) exporter. If the server can ask the client
to re-send a request with the normal Token Binding exporter, it can
accept some requests sent in 0-RTT with the 0-RTT exporter, and for
others it can request the client to re-send, which if the client is
switching exporters, it will re-send with the normal exporter.

Option 2 relies on the application layer having some mechanism that a
server can use to ask a client to retry a request - TLS has no
mechanism to reject 0-RTT data after it has been accepted (or to
request the client to re-send the 0-RTT data under 1-RTT keys). For
HTTP, I think this can be done with a 307 response code. Option 1
needs no such application layer support.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 19 Apr 2017 21:08:46 -0500

> normal exporter (i.e. the client behaves the same as in TBPROTO).

To make the obligatory statement of hopefully obvious facts, 0-RTT
data MUST NOT be used absent a profile that defines its use.
Presumably the situation of most interest here is HTTP right now,
and many people would presume that the HTTP profile for early data
will say "just concatenate the two streams", but those are just
presumptions.  Perhaps some other profile would be appropriate for
non-HTTP cases, though with no concrete proposal it hardly seems
worth time to think about other than to note that whatever decision
may be reached here might be limited to HTTP in its applicability.

If one presupposes that the profile for the use of 0-RTT is
"concatenate the streams", then the arguments against (1) are
weakened (though not entirely removed).  But I'm not sure what level
of consensus there is for such a (pre)supposition.

Having not fully thought through the matter, I still lean towards
(2), with the justification that token binding can be thought of as
an attempt to prove live possession of a key [associated to a token]
on a connection where that token is used.  The 0-RTT exporter does
not have a server contribution, so it's hard to really prove
liveness of possession using just it.  I acknowledge that there is
engineering work remainng to be done in making (2) practical/usable,
and am not really in a position to contribute much to that work, but
that's my current thinking on the matter.

-Ben

---

From: Nick Harper <[email-masked]>
Date: Thu, 27 Apr 2017 14:44:53 -0700

> of consensus there is for such a (pre)supposition.

I have definitely been assuming an application profile of HTTP that
concatenates the streams, and the use-case in mind for 0-RTT Token
Binding is with HTTP.
> that's my current thinking on the matter.

I have similar reservations for (1) in that it doesn't really prove
liveness of possession, but (2) only has this liveness of possession
at some points in the protocol (i.e. after it has switched exporters).
If a server is doing 0-RTT Token Binding, then it doesn't need the
stronger exporter for all requests - the weaker exporter is fine for
some. I don't see a reason to upgrade partway through to the stronger
exporter just because it is stronger. However, if there are use cases
for accepting the weaker exporter at the beginning of a connection but
then requiring the stronger exporter later in the connection, then (2)
sounds like a good idea. (Preferring the stronger exporter isn't
enough for this use case - it would need to require it, and absent
option (2) the implementer of this use case would put the requests
needing the stronger exporter on a separate, non-0-RTT, connection.)

For those considering implementing 0-RTT Token Binding, do you have
any such use cases in mind or is option (1) good?

---

From: Andrei Popov <[email-masked]>
Date: Thu, 27 Apr 2017 22:46:18 +0000

If one is willing to do TB without POP, then one will probably appreciate a simpler way to do this, with fewer moving parts and less room for interop issues. (IMHO, the value of TB without POP approaches zero, but that's a separate discussion.)

The extra complexity of upgrading to secure TB after a bound token and associated application message(s) have been accepted and processed does not increase security in the common use-cases that I can think of.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Nick Harper
Sent: Thursday, April 27, 2017 2:45 PM
To: Benjamin Kaduk <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding

On Wed, Apr 19, 2017 at 7:08 PM, Benjamin Kaduk <[email-masked]> wrote:
> Presumably the situation of most interest here is HTTP right now, and 
> many people would presume that the HTTP profile for early data will 
> say "just concatenate the two streams", but those are just 
> non-HTTP cases, though with no concrete proposal it hardly seems worth 
> time to think about other than to note that whatever decision may be 
> reached here might be limited to HTTP in its applicability.
>
> "concatenate the streams", then the arguments against (1) are weakened 
> (though not entirely removed).  But I'm not sure what level of 
> consensus there is for such a (pre)supposition.

I have definitely been assuming an application profile of HTTP that concatenates the streams, and the use-case in mind for 0-RTT Token Binding is with HTTP.
>
> Having not fully thought through the matter, I still lean towards (2), 
> with the justification that token binding can be thought of as an 
> attempt to prove live possession of a key [associated to a token] on a 
> connection where that token is used.  The 0-RTT exporter does not have 
> a server contribution, so it's hard to really prove liveness of 
> possession using just it.  I acknowledge that there is engineering 
> work remainng to be done in making (2) practical/usable, and am not 
> really in a position to contribute much to that work, but that's my 
> current thinking on the matter.
>
> -Ben

I have similar reservations for (1) in that it doesn't really prove liveness of possession, but (2) only has this liveness of possession at some points in the protocol (i.e. after it has switched exporters).
If a server is doing 0-RTT Token Binding, then it doesn't need the stronger exporter for all requests - the weaker exporter is fine for some. I don't see a reason to upgrade partway through to the stronger exporter just because it is stronger. However, if there are use cases for accepting the weaker exporter at the beginning of a connection but then requiring the stronger exporter later in the connection, then (2) sounds like a good idea. (Preferring the stronger exporter isn't enough for this use case - it would need to require it, and absent option (2) the implementer of this use case would put the requests needing the stronger exporter on a separate, non-0-RTT, connection.)

For those considering implementing 0-RTT Token Binding, do you have any such use cases in mind or is option (1) good?

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cc470223592b2491dd71c08d48db72ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289265288924355&sdata=H98Owo1uWbXf11VGgzmau3XH3aGzYuNA27pOOaJtxBc%3D&reserved=0

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Apr 2017 21:13:56 -0500

> The extra complexity of upgrading to secure TB after a bound token and associated application message(s) have been accepted and processed does not increase security in the common use-cases that I c…

One could perhaps concoct a case where the application layer agrees
to only send certain mundane stuff over 0-RTT but for some reason
still wants TB for it.  (That is not intended to be a compelling
argument.)

But in general, I agree with Andrei (especially with the parenthetical).

In particular, all these discussions of how once you've accepted
0-RTT TB it doesn't make sense to try to upgrade to 1-RTT are just
serving to cement my feeling that doing 0-RTT TB is a bad idea.  So,
to answer Nick's question, I have no interest in implementing 0-RTT
Token Binding, and thus don't have a use case in mind that would
make me only implement (2).  :)

-Ben