Description
Encrypted Client Hello allows to encrypt client hello fields such as SNI and ALPN list. This will hide which service (IMAP, SMTP or HTTPS) is accessed, as well as the domain (mta-sts or www).
RFC draft suggests using DNS to deliver ECH configuration, but explicitly says that "Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured.". We can deliver ECH configuration via IMAP and provider database or autoconfig XML (by extending it) to avoid depending on DoH but still encrypting client hello for all connections that happen after obtaining ECH configuration.
It seems to be safe to distribute ECH config over IMAP and cache it for arbitrary time: "A client-facing server has a set of known ECHConfig values, with corresponding private keys. This set SHOULD contain the currently published values, as well as previous values that may still be in use, since clients may cache DNS records up to a TTL or longer."
ECH config does not seem to need rotation. Worst case if private key is leaked is that we are back to the current state which is not so bad.
chatmail servers don't need SNI for anything, so public_name part of ECH config can be set to something like "example.org". This will not hide the server because anyone can just connect to the IP, but avoiding passive snooping is nice anyway.
Client-side we should be able to experiment with ECH once deltachat/deltachat-core-rust#6186 is merged.
The problem is finding the server that supports ECH. But it seems Go is going to have ECH support for servers soon as there is https://go-review.googlesource.com/c/go/+/623576 just published (2024-10-31), so some proxy like Traefik may gain ECH support.