Hi, Christopher, Thanks for reply. It seems you reply to me personally, so I resend our discussion the list.
> On Aug 23, 2022, at 22:45, Christopher Patton <cpat...@cloudflare.com> wrote: > > You're correct that the outer SNI is sent in the clear, but there is no a > priori reason why this would leak the inner SNI in a given deployment. For > example, a reverse proxy might use the same public name for all hostnames it > terminates TLS for. It may be right for a common cloud platform, but what about indie server? Every site who need ECH have to deploy an addition outer domain to *protect* the inner one. But these indie servers can not share a common outer domain, so the have to use some distinct one who doe one-to-one respond the inner one. The leak of the outer domain is equal the leak for the inner one, which make the protection for the inner one useless. > The reason we have the ECH rejection path (terminate TLS with > ClientHelloOuter and transmit updated ECH config list) is that the DNS record > obtained by the client might not be in sync with the TLS server. Imagine an > ECH enabled server that rotates the ECH config list every day or even every > hour: The higher the rotation frequency, the more likely it becomes that > somewhere in the world, some client tries to use an out-of-date DNS record. Yes, the ECH RR should be rotated, and the client may get the outdated records. We need a method to send the latest records to the client and correct it's handshake. In the meanwhile, the client needs some method to assure the new records sent from the server is valid. This is why the outer domain and TLS certificate the outer domain are needed. In order to make ECH suitable for indie servers, which not own some common outer domain, we should not depend the outer SNI and TLS handshake at all. What about make the server just send the ECH RR and it's responding RRSig to the client? By this way, the client can validate the new ECH record by the DNSSEC means. And does not need to send the outer domain at all. However, this design means the ECH depends the DNSSEC. As a result, maybe it is hard to deploy ECH because of the low rate deployment of DNSSEC. But I do not think it is a real problem. Because the ECH depends the DNS SVCB, as well. An DNS SVCB also need to be deployment from zero. Make the ECH depends the DNSSEC just make the DNSSEC has additional benefit. If you want to protect client's SNI, you have to deploy DNSSEC. And this will promote the deployment of DNSSEC too. Another benefit of this DNSSEC-style method is that we may transfer to a CA-free world. If we do not need a certificate, we do not need a CA. Drop the outer domain is the first step. If we did, the server could also publish some public key for (EC)DHE key exchange. Theses key can be verified by DNSSEC, and be used for the real TLS handshake. You register a domain, deploy the DNSSEC and then you can serve content by TLS. > On Aug 19, 2022, at 07:04, 涛叔 <h...@taoshu.in> wrote: > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
