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

[Nick Harper <[e-mail]>]

Hearing no objections to this approach, I'll update the I-D for Chicago.

On Tue, Feb 7, 2017 at 4:35 PM, Nick Harper <[e-mail]> wrote:

> 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.
>>
>
>