Subject: [Unbearable] TLS 1.3 0-RTT client authentication status

From: Bill Cox <[email-masked]>
Date: Fri, 22 Apr 2016 16:10:36 -0700

I do not think token binding or client certificates are a good idea over
0-RTT without replay protection.  The additional security of token binding
over these channels seems low compared to the security loss due to allowing
attackers to use token-bound auth tokens over 0-RTT channels without replay
protection.

The difference for servers is whether to store session state in the session
cache or ticket.  The session state has to be remembered regardless.  I
prefer server-side session caching for improved PFS and replay protection,
and it allows us to offer 0-RTT security fairly similar to TLS 1.2
resumption.  However, that's just me.  A lot of folks are sold on the
benefits of stateless servers.

Assuming this group winds up agreeing not to send bound tokens over 0-RTT
connections without replay protection, then TLS 1.3 servers should behave
in one of four ways when TB is offered by the client:

1) Servers without replay protection refuse to negotiate TB, but allow 0-RTT
2) Servers without replay protection disable 0-RTT, and negotiate TB
3) Servers with replay protection negotiate TB and disable 0-RTT
4) Servers with replay protection negotiate TB and allow 0-RTT

Unfortunately, the simplest solutions to manage at scale are 1) and 2),
since server-side caching is a bit painful.  The choice between 3) and 4)
depends on how much the server trusts the client to protect TLS secrets
between connections (the Resumption Master Secret in particular).  Clients
that manage the RMS in a trusted execution mode, as well as the token
binding private key, would be clients I would allow to connect in mode 4,
assuming my server has replay protection.

Mode 2) is particularly problematic for token binding.  It is a simple and
secure solution for servers, but they punish clients that advertise TB
support by slowing down connections.

Bill