Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?

[Nick Harper <[e-mail]>]

Here's a solution that I think would handle the case of an HTTP server
rejecting a request because it doesn't like the strength of the
exporter used for Token Binding:

- On requests sent in early data, the client uses the early exporter
(it's the only option).
- For requests sent after the handshake has completed, the client MAY
continue to use the early exporter.
- Once the client has received a response from the server, it SHOULD
switch to using the (not early) exporter for new requests on that
connection (requests that the client has already started to build but
haven't sent yet can continue using the early exporter, per the
previous point).
- A server that receives a token-bound request using the early
exporter MAY request that the client re-send the request using the
(not early) exporter. This signal would be application-specific; for
HTTP this could be done by sending a 307 status code with the Location
header pointing to the same URI. A client that implements the SHOULD
in the previous point will switch exporters by the time it re-sends
the request.

This solves the implementation problems of requiring the exporter to
match which data its sent in, and I think it offers a reasonable
solution for a server to reject a request because of exporter strength
and have the client retry it with the regular exporter. This is only
an outline of a solution and still has details that would need to be
worked out. In particular, the client needs to indicate in its
TokenBinding struct which exporter it used or the server has to do
trial verification.


On Tue, Feb 28, 2017 at 1:52 PM, Nick Harper <[e-mail]> wrote:
> On Tue, Feb 28, 2017 at 12:55 PM, Andrei Popov
> <[e-mail]> wrote:
>> Correct, the ClientHello is also needed. Not sure this makes things
>> significantly better, but it is an additional piece the attacker needs. I
>> guess we’re referring to the same attack, but disagreeing on whether “this
>> still has decent security properties”J.
>
> Yes, it sounds like we're talking about the same attack, and the
> additional piece of the ClientHello (in addition to the resumption
> PSK) doesn't change its feasibility that much. If we do any form of
> 0-RTT Token Binding, this attack will exist in some form. It is the
> major difference between 0-RTT Token Binding and regular Token
> Binding. My comment about "decent security properties" was that always
> using the 0-RTT exporter (if there is a token binding sent and
> accepted in early data) has decent security properties compared to
> using the 0-RTT exporter only for token bindings sent in early data.
>>
>>
>> It seems that the right thing to do is not allow Token Binding messages
>> until exporter_secret is available.
>
> That restriction would effectively mean that Token Binding can't be
> used with 0-RTT.