Hello, Guys, I have read the draft-ietf-tls-esni-14, and found the ECH does not protect the SNI.
Because if the client use the outdated ECH config to encrypted the ClientHelloInner, it will not be decrypted by the client facing server. In order to correct the client, the server will finish the handshake using the ClientHelloOuter, which has its own SNI. And the server will send new ECH configs encrypted by its SSL certificate. So the client can verify the new configs is valid. In my own opinion, this design only hide the original SNI, but still depends the client-facing server's domain name. It has two drawbacks: 1. If one domain want to deploy ECH in share mode, it have to offer one addition domain for the ClientHelloOuter. 2. Even the real domain will be encrypted, the shared domain don't. And if the outs domain been blocked, all the inner domain will gone. So my question is why not just use the DNSSEC method the correct the client who has some outed ECH configs? If the client-facing can not decrypted the ClientHelloInner, all it needs to do is send the new HTTPS DNS records and their RRSIGs. And the client can validate them by the DNSSEC methods. By this design, there is no need to establish the outer TLS handshake. And no additional outer domain any more. The client does not need to know or deploy two domain as well. And for almost TLS handshake, their even no need to a SSL certificates. Because we can deploy some public key by the DNS, and make a PSK handshake to the server. So why the working group does not choose the DNSSEC method? Thanks Taoshu(涛叔) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
