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

[Nick Harper <[e-mail]>]

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