Hiya,
On 23/03/2021 22:52, Christopher Patton wrote:
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
The attack is more one that allows the adversary to distinguish a real ECH attempt vs GREASE, right? So we need to start out assuming that GREASEd CH's are fairly well done. (Which is fine but might need to be explained some more in the draft maybe.)
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 theclient sent real or GREASE ECH.
Doesn't that imply that the 2nd flight message sizes, and the timing of producing (and consuming) those, mustn't allow the observer to distinguish the reaction to a real ECH vs. a GREASEd one? That may be a bit of an aside, but it may also mean that if we don't believe we can get constant time such that the passive attack here fails, then we also aren't really that worried about these active attacks. I'm also not sure we yet know how to use padding so that sizes don't give away the game. (I know I'm not yet sure about that for sure:-)
There are a number of variants of this basic attack, some of which can be pulled off without actually tipping off most clients.
Ack. And maybe there are other active attacks that could distinguish a real ECH attempt vs. GREASE based on the adversary interacting with the server - mightn't e.g. the timing of handling a simple replay of the ECH octets reveal if those were GREASE or not?
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.
You may well be right. It is hard to see a possible middle ground. There is also the 3rd option of the original use of a nonce in EncryptedExtensions - we might or might not discard that due tothe QUIC argument raised earlier I guess. S.
Chris P.
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
