Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

[Bill Cox <[e-mail]>]

On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <[e-mail]>
wrote:

> Bill Cox <[e-mail]> writes:
>
> More generally, I strongly believe that TLS 1.3 should not
> provide options which we think should be restricted to "admins who know
> what they're doing".  These end up hurting us down the line (cf EXPORT
> cipher suites.)
>
> I think we should ship the parts of 0-RTT that we believe are
> intrinsically safe for (the vast majority) of the internet to enable and
> use on day 1.
>

This is just my opinion, not Google's.  Here is a dumb idea I just had:

The current 0-RTT modes described in TLS 1.3 are clearly only for admins
who really know what they are doing.  If the current 0-RTT modes are deemed
to dangerous, then how about going back to session IDs, and doing 0-RTT
resumption from the session cache?

This is not only fairly simple given the existing code base, but it fits
well with my personal bias towards supporting strong client authentication,
which basically got thrown under the bus in the current 0-RTT scheme.
Frankly, my current job (working on token binding) is a lot less appealing
in a world where servers cannot do proofs-of-possession with clients.  With
0-RTT cached session resumption, the TLS sequence numbers remain intact,
and we inherit the security parameters from the original connection.  The
new replay attacks go away, as do most of the "new and exciting" ways to
PWN TLS 1.3 0-RTT.

The new tickets could still be supported to enable advanced operators the
flexibility they need to implement stateless 0-RTT, but from the TLS point
of view, it would just be a 0-RTT resume using a session ID, with
additional ticket data.  If the admins at a particular company want to
stuff all the session state into the ticket and accept the security
consequences of stateless 0-RTT resumption, I think they should have the
flexibility to do that.  I _think_ the new tickets give them what they need.

This would enable the standard 0-RTT resume to be as secure as keeping the
connection alive the whole time.  I think it would stop this "race to the
bottom" problem people are worried about on this thread.

So... how dumb is this idea?

Bill