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