> If I understand Martin+Jonathan's idea correctly, it is mainly about > indistinguishability of ECH handshakes across TLS servers.
I found this idea hard to understand because, in the ECH privacy threat model, distinct servers are always distinguishable by destination IP address. To start, I would like to see a realistic alternative threat model that motivates the proposed variation on ECH. I suspect the motivating threat model for some of these proposals is based on timescale assumptions: 1. The server can only acquire new public_name domains (with corresponding certificates) infrequently, due to the cost of domain registration (~weeks) 2. The attacker can only update its table of service identifiers (IPs and domain names associated with particular services) periodically due to operational overheads (~days) 3. The server can unlinkably rotate its IP address frequently using public cloud infrastructure (~hours). Assumptions like these could motivate designs that reduce the information revealed in the public_name. However, there are also good reasons to challenge some of these assumptions. I would also like to see closer analysis of the fallback flow in these proposals. In my view, the fallback flow has little value if it depends on the server to retain a private key. Instead, the server should retain the ECH private keys long enough to remove the need for fallback*. Then the public_name can be set to a reserved value like "ech.arpa" (or perhaps omitted entirely). --Ben Schwartz * We can discuss if this raises concerns about forward secrecy, given the actual distribution of lagging ECHConfig lifetimes.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
