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

[Nick Harper <[e-mail]>]

I've been thinking about this approach for a while (and what it would take
to implement it), and I've come to the conclusion that requiring switching
exporters to match the switch of encryption keys is infeasible enough that
it won't get implemented.

Instead, I propose that if a server accepts the client's 0-RTT data, then
the client uses the 0-RTT exporter for the entirety of the connection, and
otherwise the client uses the exporter as already specified in TBPROTO.
This still has decent security properties.

First, consider a server that is uncomfortable enough with the early
exporter that it does not want to accept any token bindings that use that
exporter. This server rejects all early data on connections where the
client tries to negotiate token binding, and falls back on using the
existing exporter in TBPROTO with no early data.

Next, consider a server that does accept some requests sent in early data
with a token binding that used the early exporter (the only choice in a
request in early data). For this request, since the server accepted it, it
has decided that the early exporter provides enough security to verify the
binding (otherwise this server would be in the above category). If the
early exporter was good enough for this server on a request sent in early
data, then surely that server would accept the same request (with the same
token binding) when sent under the forward-secure encryption keys.

A server accepting early data should accept any request sent in early data.
The server can't sniff the early data to reject it if it contains a request
it doesn't like (e.g. a POST request), because the early data could contain
multiple requests (e.g. in the case of HTTP/2), and the server MUST process
the ClientHello and immediately send the ServerHello - it cannot wait to
process all of the client's early data. It follows that if a server will
accept a token-bound request in early data, then it will accept any
token-bound request in early data, meaning that the server finds the early
exporter used for the token binding acceptable no matter the request. If
the server is fine with the early exporter for every request, then it
should accept the early exporter when it is used for requests not sent in
early data as well. In other words, if the server does not want to allow
the early exporter to be used for token bindings on some requests, then the
only logical thing for that server to do is always reject early data if
token binding is negotiated.

On Fri, Jan 13, 2017 at 2:18 PM, Andrei Popov <[e-mail]>
wrote:

> Ø  Another way to move the change in exporters out of the client's
> control would be to do it at a time that is implicit in the protocol. An
> obvious choice would be switch exporters when the client switches from
> sending early data to sending data post-handshake.
>
> I think this type of approach is better.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[e-mail]] *On Behalf Of *Nick
> Harper
> *Sent:* Friday, January 13, 2017 12:30 PM
> *To:* IETF Tokbind WG <[e-mail]>
> *Subject:* [Unbearable] 0-RTT Token Binding: When to switch exporters?
>
>
>
> The current tokbind 0-RTT draft has the TLS 1.3 early exporter value used
> in the TokenBinding.signature for the entirety of the connection. One point
> of discussion that came up in Seoul was that we shouldn't use the 0-RTT
> exporter for too long. I agree that we shouldn't use it for too long, but I
> can't remember (or figure out from the meeting notes) if the reason is just
> because we prefer the crypto properties of the normal exporter, or are we
> also trying to prevent an attacker from being able to use the 0-RTT
> exporter indefinitely?
>
>
>
> For the first case, the switch from the 0-RTT exporter to the normal
> exporter can be client-initiated. One possible design would be to have the
> client send an extension in the TokenBinding indicating that all future
> TokenBindings will use the normal exporter. This would function similar to
> the ratcheting idea (from section 4.1 of the I-D), but the ratchet doesn't
> take effect until this indicator extension is sent (before it's sent the
> server would accept both exporters). This would likely be done in
> combination with the idea of defining new key types to indicate that the
> 0-RTT exporter is in use so the server doesn't do trial verification.
>
>
>
> If we want to move the switch from 0-RTT exporter to normal exporter out
> of the client's control (so that an attacker can't keep using the 0-RTT
> exporter indefinitely), a different solution is needed. One possible idea
> is to have the server send a message that conceptually means "all future
> TokenBindings must not use the 0-RTT exporter". Right now, Token Binding
> doesn't have any server-to-client messages, so this would require defining
> application-specific messages. Another way to move the change in exporters
> out of the client's control would be to do it at a time that is implicit in
> the protocol. An obvious choice would be switch exporters when the client
> switches from sending early data to sending data post-handshake.
>