Re: [Unbearable] Switching exporters for 0-RTT Token Binding

[Benjamin Kaduk <[e-mail]>]

On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote:
> 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).

To make the obligatory statement of hopefully obvious facts, 0-RTT
data MUST NOT be used absent a profile that defines its use.
Presumably the situation of most interest here is HTTP right now,
and many people would presume that the HTTP profile for early data
will say "just concatenate the two streams", but those are just
presumptions.  Perhaps some other profile would be appropriate for
non-HTTP cases, though with no concrete proposal it hardly seems
worth time to think about other than to note that whatever decision
may be reached here might be limited to HTTP in its applicability.

If one presupposes that the profile for the use of 0-RTT is
"concatenate the streams", then the arguments against (1) are
weakened (though not entirely removed).  But I'm not sure what level
of consensus there is for such a (pre)supposition.

Having not fully thought through the matter, I still lean towards
(2), with the justification that token binding can be thought of as
an attempt to prove live possession of a key [associated to a token]
on a connection where that token is used.  The 0-RTT exporter does
not have a server contribution, so it's hard to really prove
liveness of possession using just it.  I acknowledge that there is
engineering work remainng to be done in making (2) practical/usable,
and am not really in a position to contribute much to that work, but
that's my current thinking on the matter.

-Ben