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

[Andrei Popov <[e-mail]>]

I haven’t thought through all the permutations of TLS 1.3, but it seems that you’re right and it is possible for a client to only use “proper TB” without negotiating “replayable” vs. “proper” TB options, by keeping some extra state associated with the resumption secret. If the WG decides to go ahead with 0-RTT TB, then we should at least describe the behavior of a client and server that avoids mixing TB with 0-RTT. This will be particularly important for clients and servers that care about malware enough to support TB key attestation.

Cheers,

Andrei

From: Nick Harper [mailto:[e-mail]]
Sent: Tuesday, March 21, 2017 5:20 PM
To: Andrei Popov <[e-mail]>
Cc: Eric Rescorla <[e-mail]>; IETF Tokbind WG <[e-mail]>; Martin Thomson <[e-mail]>
Subject: Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?


On Tue, Mar 21, 2017 at 13:26 Andrei Popov <[e-mail]<mailto:[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