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

[Andrei Popov <[e-mail]>]

If one is willing to do TB without POP, then one will probably appreciate a simpler way to do this, with fewer moving parts and less room for interop issues. (IMHO, the value of TB without POP approaches zero, but that's a separate discussion.)

The extra complexity of upgrading to secure TB after a bound token and associated application message(s) have been accepted and processed does not increase security in the common use-cases that I can think of.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[e-mail]] On Behalf Of Nick Harper
Sent: Thursday, April 27, 2017 2:45 PM
To: Benjamin Kaduk <[e-mail]>
Cc: IETF Tokbind WG <[e-mail]>
Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding

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?

_______________________________________________
Unbearable mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cc470223592b2491dd71c08d48db72ee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289265288924355&sdata=H98Owo1uWbXf11VGgzmau3XH3aGzYuNA27pOOaJtxBc%3D&reserved=0