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

[Andrei Popov <[e-mail]>]

Hi Nick,

> Second replay of a TokenBinding message on a new connection (where the exporter is the same). This involves client malware, which can just as easily do private key operations to generate new TokenBinding messages to use on new connections. In TBPROTO, this is also possible, but it can only be done for active connections. With 0-RTT, the attacker can do this for connections that will be created up to 7 days in the future.

A basic property of Token Binding is that malware can't export the token and successfully use it from another machine, as long as it cannot also export the TB key. This is a useful property, because it means that once the client malware is removed, the attack is immediately stopped. This property is not present when Token Binding is used in combination with 0-RTT, because it may be possible for the malware to export the TLS 1.3 resumption secret.

> If a server's threat model does not include client malware, i.e. the server is only using Token Binding to protect against attacks like XSS (e.g. to protect cookies without the HttpOnly flag set, or OAuth tokens), then enabling both TB and 0-RTT is perfectly reasonable.
> Depending on the server's policies, even if client malware is in its threat model it still could find the 7 day window acceptable.

Yes, I can easily imagine servers with such policies:). 
If the WG decides to allow the use of TB in combination with 0-RTT, then we should at least provide a way for the client to negotiate replayable/0-RTT TB option separately. This would allow a client to opt out of "replayable TB", while avoiding reauthentication on every connection. A server that receives a TLS 1.3 ClientHello advertising "proper TB" (and not "replayable TB") would either not negotiate Token Binding, or reject 0-RTT resumption with this client (and instead do a full handshake).

A different client would be able to offer both "proper TB" and "replayable TB". Such a client would use the 0-RTT exporter throughout all 0-RTT connections, simplifying the rules... Would this work for you, Nick?

Cheers,

Andrei