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

On Sat, May 6, 2017 at 4:54 PM, Kyle Rose <krose@krose.org> wrote:

> On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara <ilariliusvaara@welho.com
> > 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.
>

Correct.

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

Correct.

-Ekr

>
> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>