Re: [TLS] Simple, secure 0-RTT for the masses

[Colm MacCárthaigh <[e-mail]>]

On Tue, Mar 15, 2016 at 4:59 PM, Bill Cox <[e-mail]> wrote:

> I prefer your solution, but it would require getting the TLS 1.3 protocol
> changed.  TLS 1.3 seems to be geared towards making stateless resumption
> with reusable tickets.
>

We keep circling that alright, and it doesn't work without sacrificing FS
and/or replay-protection :(


> The issue seems to be that in TLS 1.3, tickets are reusable multiple times
> to resume sessions, so we can't store the TLS sequence number in the
> ticket.  If this were being used for an actual pre-shared key resumption,
> it would probably be OK, but it seems to break security in multiple ways
> when using tickets for TLS 1.2-style resumption, leaving us with no choice
> but to emulate the continuation of the TLS sequence numbers (and PRF
> state?  Is that needed?).
>

Sorry; I confused things by saying with PRF-state, but what I had in mind
there was turning the crank on the PRF to derive new encryption and mac
keys for the resumed session. If you do it that way; and if the PRF
provides anti-backtracking, then compromising the session cache can only be
used to decrypt future resumed connections, rather than anything previously
collected or currently active. If you're going to increment state for each
resumption; might as well provide forward secrecy too.

Protocols seem to fall into two camps.  The ones that require replay
> resistance from the TLS layer all seem to terminate TLS connections in the
> same place so that the session cache can be safely and efficiently
> synchronized, avoiding replay attacks even when using 0-RTT.  For example,
> when ssh-ing into a machine, that one machine terminates the connections,
> and can have a shared cache.  None of the 0-RTT TLS-layer replay attacks
> I've read seem to work against a single server-side session cache.
>

I think I agree with that; but maybe would state it as: we can preserve
forward secrecy and replay mitigation for 0RTT data, but at the cost of
read-after-write consistency from a server-side data-store. The store
needn't be transactional, an eventually consistent store could be used: but
the miss-rate would be elevated over what we see today. So it would work
better in the single server case than the many distributed servers case -
but could work for both.


> The other camp is HTTP-like protocols that terminate all over the place.
> These all seem to be replay-tolerant because random network errors will
> cause random replays, and there is no efficient way to synchronize the
> session cache globally.
>

I think that's a dangerous position too. Triggering browser retries
requires a certain level of difficulty and has a certain amplification
factor. Sniffing wifi and sending a TCP message is far easier. An attacker
could exhaust things like server-side request throttling limits far more
quickly with the latter than the former. Besides: lowering our own levels
of security because other tools have already done the same is just another
race to the bottom.

-- 
Colm