> I think the right thing here would be to analyse that attack > again and re-evaluate which of the two answers now seems > best. For me, the github issue discussion didn't leave > behind enough information to do that. (Or I need to stare > at it some more maybe:-) >
If we constrain the model so that the "don't stick out" attacker is passive, then PR#287 (https://github.com/tlswg/draft-ietf-tls-esni/pull/287 suffices). The attack described at the top of PR#353 ( https://github.com/tlswg/draft-ietf-tls-esni/pull/353) is what led everyone to agree that the acceptance confirmation needed to be derived from the secret shared by the client and backend server. It's an active "don't stick out" attack. Basically, the attacker replies to the client's CH with a bogus SH; and by observing the client's reply, it can learn whether the client sent real or GREASE ECH. There are a number of variants of this basic attack, some of which can be pulled off without actually tipping off most clients. If we intend to thwart active "don't stick out" distinguishers, then PR#353 seems necessary to me. The key difference between PR#287 and PR#353 is that, in the latter, the secret used to derive the acceptance signal is authenticated. This isn't true in the former. I don't think trying to find a middle ground between PR#353 and PR#287 will be fruitful, unless we can hack in backend-server authentication by some means other than the handshake signature. Chris P.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
