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

[Benjamin Kaduk <[e-mail]>]

On Tue, Jul 11, 2017 at 02:53:25PM -0700, Nick Harper wrote:
> On Sat, Jul 1, 2017 at 9:53 AM, Benjamin Kaduk <[e-mail]> wrote:
> > Hi Nick,
> >
> > On Thu, Jun 29, 2017 at 08:16:33PM +0000, Andrei Popov wrote:
> >> 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.
> 
> 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.

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.


> > 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
> 
> 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 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.


> 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.

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