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

[Bill Cox <[e-mail]>]

On Tue, Mar 15, 2016 at 1:21 PM, Colm MacCárthaigh <[e-mail]>
wrote:

>
> Here the resumption counts have to be synchronized between the client and
> server, but is the count cryptographically authenticated? can can attacker
> can take 0RTT data from session N, increment the resumption count, and
> replay that 0RTT data?
>

Crud, your right.  You broke that protocol in record time!  To make this
work with the existing TLS 1.3 spec, I think the server will have to
encrypt the ticket, which involves the whole ticket encryption key
management overhead.  Yuk.


> Since synchronization and authenticity are both required here, would it be
> simpler to use the sequence number and PRF state from the session? it can
> be saved by the client and server on session close, and they take off where
> they left things on any subsequent connection. That also gives clients and
> their users additional confidence in the protocol: the server can't just
> ignore things like resumption counts.
>

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.

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

Another sort of warm and fuzzy reason I like this is that the whole thing
> resembles a single-long-running regular TLS connection over a single TCP
> socket. That makes things easier to verify, and some things easier to
> implement.
>

That's the idea... but hard to implement, and not at all documented.


> To see that this provides roughly TLS 1.2 security, note that so long as
>> the protocol never has to drop to 1-RTT, it is basically equivalent to TLS
>> 1.2 session-ID based resumption.  When we do drop down to 1-RTT, we will
>> replay 0-RTT application data, opening up new replay attacks.  However,
>> after this paper
>> <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>, I do
>> not believe there are any significant new replay attacks against HTTPS,
>> ssh, or any real protocol I can think of.
>>
>
> Unfortunately I don't think that's a safe assumption. The paper is about
> browser behavior, but there are API clients and SDKs that do not retry as a
> matter of design, they rely on TLS for non-replayability. In any event,
> there might be no problem: wouldn't it be a TLS library bug if the library
> somehow fell back to 1-RTT mode while also decrypting and passing on the
> 0RTT data? the client and the server need to agree on whether it was
> received.
>

This is worth more careful examination.  Each new protocol should be
analyzed for compatibility with session-cache based 0-RTT.  However, I have
not found any protocols that would have a problem.  Can you?

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.

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.

Bill

>
>