[Unbearable] Switching exporters for 0-RTT Token Binding

[Nick Harper <[e-mail]>]

One of the issues raised in Chicago around 0-RTT Token Binding is
whether or not to switch from the 0-RTT exporter to the normal
exporter, and I'd like to get some feedback from the Working Group on
this.

The two options I'm considering are as follows:
1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted.
2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT.
The client switches to using the normal exporter soon after the
handshake finishes, but it may send some Token Binding messages
post-handshake using the 0-RTT exporter.
In both cases, if the server rejects 0-RTT data, the client uses the
normal exporter (i.e. the client behaves the same as in TBPROTO).

I'm currently leaning towards option 1. Below are my arguments for
each option. I'm interested in hearing additional arguments
for/against each option and what people's preference is. I'm
particularly interested in the opinion of server operators who would
be implementing this.

For option 1:
Option 1 is simple to implement. No extension (or other mechanism) is
needed in the TokenBinding struct to indicate which exporter was used
to avoid the server needing to do trial verification. Code paths are
simpler on both the client and server when the exporter value remains
constant for the whole connection.

When a server is choosing whether to accept or reject 0-RTT data, it
cannot base this decision on the content of the 0-RTT data, which
means that a server that chooses to accept a 0-RTT Token Binding makes
that decision without knowing what the message contents are. It
follows that said server finds the security properties of 0-RTT Token
Binding acceptable on any request received in 0-RTT. If a server finds
the security properties of 0-RTT Token Binding acceptable on a request
when it is received in 0-RTT data, then it would only be logical for
it to find those security properties acceptable when that request is
not in 0-RTT data (i.e. post-handshake), and since that server will
accept any message (with 0-RTT Token Binding) in 0-RTT data (because
it can't choose whether or not to do 0-RTT based on message contents),
there would be no case where the server would only accept the normal
exporter.

For option 2:
A server might have some requests where it is fine with the security
properties of 0-RTT Token Binding, and others where it wants the full
protection of the (normal) exporter. If the server can ask the client
to re-send a request with the normal Token Binding exporter, it can
accept some requests sent in 0-RTT with the 0-RTT exporter, and for
others it can request the client to re-send, which if the client is
switching exporters, it will re-send with the normal exporter.

Option 2 relies on the application layer having some mechanism that a
server can use to ask a client to retry a request - TLS has no
mechanism to reject 0-RTT data after it has been accepted (or to
request the client to re-send the 0-RTT data under 1-RTT keys). For
HTTP, I think this can be done with a 307 response code. Option 1
needs no such application layer support.