Hi Experts,
I am not a strong person on encryption, but it is evident for me that "TLS
Encrypted Hello"
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no value in
fighting censorship.
Whatever DNS name would be used for "client-facing server", it is easy for a
particular country authority to drop traffic directed to it. Because transit
traffic to the real content owners ("backend servers") would not be
affected.
It is especially useless to use a special DNS name (like cloudflare-ech.com)
for "TLS Encrypted Hello" - it is a clear instruction for the country
authority on what to drop.
The fundamental problem here that censors may drop selectively, only to
cloudflare-ecn.com, not to github.com (or many other services). It is not a
situation when they have a danger to completely isolate the country.
Clients would start investigating what has changed in the browser to disable
ECH. It would not work in the same way as it happened for the full SNI
encryption.
I could propose the better logic:
1. The client is choosing SNI randomly among many existing (if service
hiding is needed) or using the real SNI (if hiding is not needed) to write
into the OuterHello.
2. The client encrypts InnerHello with the public key of "client-facing
server" (if service hiding is needed) or with the public key of the "backend
server" (if hiding is not needed).
3. The "client-facing server" should always try to decrypt the
InnerHello with its own private key (independent of outer SNI).
If successful, then the real destination could be read from the InnerHello,
If not successful, then the Outer SNI was real.
The censor could not repeat the last step - they do not have the private key
of the "client-facing server".
It is probably not a big burden to ask "client-facing server" to decrypt all
Hello.
It could look that for such a solution, censor could not drop selectively.
They may put them into the dilemma of complete country isolation.
Actually not, they could. The problem that the presence of encrypted
InnerHello is enough to block such solution from proliferation.
You could try to use dummy InnerHello for many years to drive situation to
the case when all Hello has it but it is not used. Then activate InnerHello
on the one day in the browser update.
In such a way you could put censors into the situation "block everything or
nothing".
The only real solution would be to have a sort of VPN to CDN providers:
* The initial Hello would be used to establish communication with
"client-facing server" (some sort of VPN)
* Then second Hello would be to the "backend server"
It has 2 big drawbacks:
* Connection would be established in two RTT instead of one.
* It is a risk for CDN business. If CDN providers would not introduce
such a VPN service synchronously (highly probably), censor would be capable
to punish them one by one
Hence, I am pessimistic that ECH (or whatever) would permit to fight
censorship.
It is a fundamental requirement to show real service to have the capability
to forward it to the content provide that has a private key to decrypt.
If service is shown then censorship is possible.
PS: Please, keep me on copy of communication - this email is not connected
to datatracker.
Ed/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
