On 9/10/2020 12:43 PM, Christopher Patton wrote: > Hi Mike, > > I've since updated the proposal to address the replay attack, but not > Christian's MITM attack: > https://github.com/tlswg/draft-ietf-tls-esni/pull/287 > > A quick question about Chrisitian's suggestion of using the > "key_shares" to derive the hint. I believe a slightly stronger variant > of the MITM attack beats this mitigation: suppose the server replays > not only the original hint, but also the original "key_shares" shares > extension. It won't be able to decrypt the client's response, but > can't the attacker still detect ECH usage?
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. 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. -- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
