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

[Nick Harper <[e-mail]>]

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.