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

[Nick Harper <[e-mail]>]

On Wed, Apr 19, 2017 at 7:08 PM, Benjamin Kaduk <[e-mail]> wrote:
> 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.

I have definitely been assuming an application profile of HTTP that
concatenates the streams, and the use-case in mind for 0-RTT Token
Binding is with HTTP.
>
> 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

I have similar reservations for (1) in that it doesn't really prove
liveness of possession, but (2) only has this liveness of possession
at some points in the protocol (i.e. after it has switched exporters).
If a server is doing 0-RTT Token Binding, then it doesn't need the
stronger exporter for all requests - the weaker exporter is fine for
some. I don't see a reason to upgrade partway through to the stronger
exporter just because it is stronger. However, if there are use cases
for accepting the weaker exporter at the beginning of a connection but
then requiring the stronger exporter later in the connection, then (2)
sounds like a good idea. (Preferring the stronger exporter isn't
enough for this use case - it would need to require it, and absent
option (2) the implementer of this use case would put the requests
needing the stronger exporter on a separate, non-0-RTT, connection.)

For those considering implementing 0-RTT Token Binding, do you have
any such use cases in mind or is option (1) good?