Re: [Unbearable] I-D Action: draft-ietf-tokbind-tls13-0rtt-02.txt

[Benjamin Kaduk <[e-mail]>]

Hi Nick,

On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote:
>   *   A good point,  if the attacks are still possible then supporting 0-RTT is problematic.
>   *   On the other hand 0-RTT is a big speed boost for resumed connections.  It is hard to imagine that servers are going to disable it to use token binding over the long term.
> 
> There is often a tradeoff between security and performance; some servers may choose 0-RTT based on their business requirements, and others may choose TB. I do not think that it is necessary to reconcile TB and 0-RTT (although it would have been awesome if we could). From my perspective, it is more important to keep TB secure than to make it work with 0-RTT: replayable TB would be a waste of CPU cycles.

I agree with Andrei that there is a tradeoff and keeping TB secure is important.

For a long time I have been generally opposed to 0-RTT TB at a gut level,
but I may have recently gained an intuition for how to articulate my
concerns in a more concrete fashion.  That is, as a server, I am interested
in TB providing binding to the channel between the client and myself.
But, since 0-RTT does not include any server contributions, in some sense
0-RTT TB is only binding to "half of the channel" (the client's contribution),
and even though it is/ends up being bound to my (as the server) connection
to the client, the same octets on the wire could also end up being bound
to a different connection emanating from the client.  So I as a server
have a weaker security guarantee, and I would prefer to retain the stronger
security property.

-Ben