Hi Christian, No, I don't think the server can detect ECH usage by doing that. The > client will complete the exchange as if connected to the server. The > client's response would pretty much the same as if the server's response > had not been modified, and the MITM will not be able to test whether > this is ECH or not. If it could, ECH would be seriously broken. >
I think we should be careful with the word "broken" ... here we're talking about "don't stick out", which is a deployment consideration only. The main security goal is confidentiality of the ClientHelloInner. > But there may be some attack plausible by playing with the ciphersuite, > or maybe the TLS version extension. I don't think so, but I can't prove > it either way. One solution would be to incorporate more elements in the > hash. Another would be to serialize the whole server hello, with a > proforma random, and add to the hint hash the server hello bytes that > follow the "random" part. > The latter seems to be the lowest cost in terms of implementation complexity. Nevertheless, I continue to believe that its cost outweighs the benefit of this mechanism. To summarize my reasons: 1. The class of active attacks it addresses is quite narrow, and we have no reason to believe that it poses a deployment risk to ECH. (It certainly doesn't invalidate the main security goal.) 2. We know of much simpler active attacks for distinguishing real ECH from cover ECH, which means the intended threat model isn't fully addressed. 3. Any future mechanism that rigorously addresses the intended threat model will replace what we specify today. It seems like good hygiene to keep the thing we'll be replacing as simple as possible. The current proposal (https://github.com/tlswg/draft-ietf-tls-esni/pull/287) doesn't stick out much to passive attackers, and it even mitigates (accidental) replay attacks. This ought to be enough to begin experimenting with deployment. We won't know what the real-world deployment risks are until we do. Best, Chris P.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
