[TLS] ECH not protect SNI

[涛叔 <[e-mail]>]

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(涛叔)