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

[Nick Harper <[e-mail]>]

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