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

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 1 Jul 2017 11:53:17 -0500

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

---

From: Nick Harper <[email-masked]>
Date: Tue, 11 Jul 2017 14:53:25 -0700

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

I agree that there are trade-offs to be made between security and
performance, and I agree that some clients and servers when choosing
to do Token Binding will want it to be as secure as possible. I'm a
little confused by what you mean when you say "keeping TB secure is
important". 0-RTT TB does not change the security properties of the
existing TB in TBNEGO/TBPROTO.
> have a weaker security guarantee, and I would prefer to retain the stronger

There is a server contribution to the exporter value signed in 0-RTT
TB - the server contribution is the PSK from the NewSessionTicket
issued on the original connection. 0-RTT TB is just like using client
certificates with TLS resumption: with client certificates there is
only a signature on the original connection, and the client auth state
is carried over from the previous connection on resumption. With 0-RTT
TB, there is a signature on both the original and resumed connection,
but this signature just proves that the private key was used at the
beginning of the original connection (since the resumed connection's
signature could hypothetically be computed then as well). In both
cases - client certs and 0-RTT TB - we have proof of possession of the
private key at the beginning of the original connection, but not at
the beginning of the resumed connection. I think having comparable
security to client certificates is a decent bar that 0-RTT TB meets.

I know that 1-RTT TB meets a higher security bar, and I don't expect
to convince those wanting to trade performance for this additional
security that they should implement 0-RTT TB. I'm trying to make the
case that 0-RTT TB is not a waste of resources and that it provides a
decent level of security for those wishing to use it.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 11 Jul 2017 19:23:51 -0500

> existing TB in TBNEGO/TBPROTO.

My interpretation was (to very very roughly paraphrase) that this is a
question of branding -- that is, when we say that something is secured
with Token Binding, we want that to mean the high level of security.

> security to client certificates is a decent bar that 0-RTT TB meets.

I agree about the transitive contribution.  My intent was to indicate
a desire for a current/fresh server contribution that is specific to the
current connection.

I'm also not sure that using client certificates as a comparison is the
right place to set the bar.

> decent level of security for those wishing to use it.

I mean, you should probably continue to make your case.  At some point
the WG will have to decide whether it is "good enough" to merit the
stamp of approval as an okay thing for consumers of TB to be able to
choose to use (or not use).

-Ben