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

[Nick Harper <[e-mail]>]

It sounds like the consensus on this thread is that 0-RTT TB should
use the 0-RTT exporter for the whole connection - switching exporters
adds complexity, and no use cases have been identified where it
provides extra value. I will update the draft to have it not switch
exporters. Once I make the language change around switching exporters
and also resolve the 4 issues currently open on
https://github.com/nharper/0-rtt-token-binding/issues, I'll upload a
new I-D.

On Thu, Apr 27, 2017 at 7:13 PM, Benjamin Kaduk <[e-mail]> wrote:
> On Thu, Apr 27, 2017 at 10:46:18PM +0000, Andrei Popov wrote:
>> 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.
>
> One could perhaps concoct a case where the application layer agrees
> to only send certain mundane stuff over 0-RTT but for some reason
> still wants TB for it.  (That is not intended to be a compelling
> argument.)
>
> But in general, I agree with Andrei (especially with the parenthetical).
>
> In particular, all these discussions of how once you've accepted
> 0-RTT TB it doesn't make sense to try to upgrade to 1-RTT are just
> serving to cement my feeling that doing 0-RTT TB is a bad idea.  So,
> to answer Nick's question, I have no interest in implementing 0-RTT
> Token Binding, and thus don't have a use case in mind that would
> make me only implement (2).  :)
>
> -Ben