On Sat, May 6, 2017 at 4:54 PM, Kyle Rose <kr...@krose.org> wrote: > On Sat, May 6, 2017 at 11:12 AM, Ilari Liusvaara <ilariliusva...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
