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

[Nick Harper <[e-mail]>]

On Tue, Mar 21, 2017 at 13:26 Andrei Popov <[e-mail]>
wrote:

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

I agree that both the client and the server should be able to opt out of
"replayable TB" and be able to do "proper TB" or 0-RTT as they wish. I'd be
happy with providing a way for negotiating "replayable TB" separately from
"proper TB" and using the 0-RTT exporter for the entirety of 0-RTT
connections. I'm also ok with switching exporters for "replayable TB" if
the WG prefers that.

If we need to, I could propose a new TLS extension to negotiate "replayable
TB", which the client and server can use to negotiate that separately from
"proper TB". However, I think we can design it so that extension isn't
needed.

Let's consider a client that supports TB and 0-RTT, but would prefer to do
"proper TB", speaking to a server that supports "replayable TB". Before the
client can make a 0-RTT connection to the server, it needs to make a 1-RTT
connection to get a PSK it can use for resumption (and 0-RTT). When it
makes this 1-RTT connection, it learns that the server supports both 0-RTT
and TB, so the client could make a note not to use that PSK for 0-RTT (only
use it for 1-RTT resumption). Let's also consider a server that when it
issued the NewSessionTicket to the client did not support TB (so the client
is going to use this NST for a 0-RTT connection), but when the client
initiates the 0-RTT connection, the server now supports TB. One option is
for the client to exclude the TB extension from its ClientHello and send
the EarlyDataIndication extension. This results in the client making a
connection without TB even though both endpoints support it. Instead, the
client should send the TB extension and the EarlyDataIndication extension.
(The early data won't contain a bound token.) The server when choosing
whether or not to accept early data will follow rules that the result of
negotiating the TB extension must be the same on the resumed connection as
on the connection where the NST was issued, and since the NST was issued on
a connection without TB, but this connection would negotiate TB, the server
rejects early data and negotiates TB. (This is the same behavior for early
data as the ALPN and SNI extensions.)

A server that supports TB and 0-RTT, but not "replayable TB" can implement
this much easier. If a ClientHello arrives with only one of the two
extensions (TB or EarlyDataIndication), it negotiates whichever is present
as normal. If both are present, the server can unconditionally reject early
data if it negotiates TB.

I realize the client scenario is a bit complicated, and I might not have
explained it well. Does this provide a clear enough signal (for both sides)
between "proper TB" and "replayable TB"?

>
> Cheers,
>
> Andrei
>