Re: [TLS] The case for a single stream of data

[Kyle Rose <[e-mail]>]

On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sat, May 06, 2017 at 09:43:55AM -0400, Kyle Rose wrote:
> > I asked this question a while back, and didn't get a satisfying answer:
> if
> > an on-path attacker replaces the early data with a replay from an earlier
> > connection, does the server eventually figure this out once the handshake
> > is complete, or is this mix-and-match impossible for the server to
> detect?
> > It would be nice if a security property of early data is that a replay
> > attack is eventually detected, because at least then you'll know you're
> > under attack.
>
> Trying to replace the early data leads to fatal handshake error if the
> server accepts 0-RTT (since actual deprotection failure from 0-RTT data
> is fatal). If server rejects, then the substitution is silently ignored.
>

I'm not sure this completely answers my question, so let me propose where I
think protection lies.

If the on-path attacker replaces only the early data bytes, deprotection of
early data will fail since the early traffic secret incorporates the
ClientHello in its derivation, which includes a (presumably) fresh client
random.

If the on-path attacker replaces the entire first flight (or at least
ClientHello and the early data), the early data may be accepted but the
subsequent handshake will fail because the client and server will derive
different handshake traffic keys.

If this is accurate, then replays of partial requests don't really pose a
problem (at least for HTTP) because the remainder of the request will fail
deprotection and so the request won't actually be delivered to the
application.

Kyle