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

[Andrei Popov <[e-mail]>]

Ø  Another way to move the change in exporters out of the client's control would be to do it at a time that is implicit in the protocol. An obvious choice would be switch exporters when the client switches from sending early data to sending data post-handshake.
I think this type of approach is better.

Cheers,

Andrei

From: Unbearable [mailto:[e-mail]] On Behalf Of Nick Harper
Sent: Friday, January 13, 2017 12:30 PM
To: IETF Tokbind WG <[e-mail]>
Subject: [Unbearable] 0-RTT Token Binding: When to switch exporters?

The current tokbind 0-RTT draft has the TLS 1.3 early exporter value used in the TokenBinding.signature for the entirety of the connection. One point of discussion that came up in Seoul was that we shouldn't use the 0-RTT exporter for too long. I agree that we shouldn't use it for too long, but I can't remember (or figure out from the meeting notes) if the reason is just because we prefer the crypto properties of the normal exporter, or are we also trying to prevent an attacker from being able to use the 0-RTT exporter indefinitely?

For the first case, the switch from the 0-RTT exporter to the normal exporter can be client-initiated. One possible design would be to have the client send an extension in the TokenBinding indicating that all future TokenBindings will use the normal exporter. This would function similar to the ratcheting idea (from section 4.1 of the I-D), but the ratchet doesn't take effect until this indicator extension is sent (before it's sent the server would accept both exporters). This would likely be done in combination with the idea of defining new key types to indicate that the 0-RTT exporter is in use so the server doesn't do trial verification.

If we want to move the switch from 0-RTT exporter to normal exporter out of the client's control (so that an attacker can't keep using the 0-RTT exporter indefinitely), a different solution is needed. One possible idea is to have the server send a message that conceptually means "all future TokenBindings must not use the 0-RTT exporter". Right now, Token Binding doesn't have any server-to-client messages, so this would require defining application-specific messages. Another way to move the change in exporters out of the client's control would be to do it at a time that is implicit in the protocol. An obvious choice would be switch exporters when the client switches from sending early data to sending data post-handshake.