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

[Nick Harper <[e-mail]>]

I'd like to update the I-D to address the concern of which exporter to
use when. I know that this update will not address the recent concern
around proof of possession of the TB key in 0-RTT, and we can discuss
that concern at IETF 98 in Chicago. Below is an outline of how I plan
to handle changing exporters. Does it sound reasonable to update the
I-D now, even with the open concern around proof of possession?

Outline for changing exporters:
In early data, the client uses the early exporter.
Upon receiving an application-layer response from the server, the
client switches to the regular exporter. (The client may have some
requests that were sent after the TLS handshake completed but still
using the early exporter.)
The above switch allows a server to on a per-request basis decide that
the signature of the early exporter was not sufficient and have the
client re-send the request with the regular exporter. In http, this
can be done by the server responding with a 307 redirecting to the
same resource (optionally with an additional query param indicating
that said redirect happened).

In the TokenBinding struct for any Token Binding whose signature is of
the early exporter, the client includes an Extension with
ExtensionType early_exporter(TBD) and 0-length extension_data to
indicate that the server should verify the signature using the early
exporter instead of the normal exporter.

On Wed, Mar 1, 2017 at 5:36 PM, Nick Harper <[e-mail]> wrote:
>> -----Original Message-----
>> From: Martin Thomson [mailto:[e-mail]]
>> Sent: Wednesday, March 1, 2017 4:53 PM
>> To: Nick Harper <[e-mail]>
>> Cc: Andrei Popov <[e-mail]>; IETF Tokbind WG <[e-mail]>
>> Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?
>>
>> Would it help to include a clear signal about which keys are intended to be exported and used?
>
> Yes, I plan to include some sort of signal so that the server doesn't
> have to do trial verification. This could be defining a new set of key
> types that when used in a TokenBinding struct indicate the signature
> is over the early exporter, or it could be an indicator extension in
> the TokenBinding struct (or maybe something else). The former has the
> benefit that it is covered by the signature (unless the signature
> format changes).
>
>
> On Wed, Mar 1, 2017 at 4:54 PM, Andrei Popov <[e-mail]> wrote:
>> This solution introduces a lot of complexity, but does not address the fundamental problem, which is that the client can't prove possession of the TB key in 0-RTT. So, if I have a site that requires strong protection of tokens with TB, I would disable 0-RTT application data, or at least reject requests that arrive in 0-RTT and require bound tokens to be authorized.
>
> The signature over the early exporter proves that the client had
> possession of the TB key sometime after the server issued the
> NewSessionTicket used for starting the 0-RTT connection. Whether this
> is good enough depends on the threat model of the server. Obviously a
> server that is paranoid can choose to reject 0-RTT data if Token
> Binding is also negotiated on the connection, and I'm fine with that.
> However, a server may decide that it is not concerned with client
> malware stealing a NewSessionTicket (and corresponding data to replay
> a 0-RTT TokenBindingMessage), and find this proof of possession good
> enough.
>
> 0-RTT data has different security properties than 0.5-RTT or
> post-handshake application data in TLS 1.3, so it's reasonable for a
> TokenBindingMessage sent in 0-RTT application data to have different
> security properties.