Hi Stephen, Thank you for understanding :)
> On Aug 24, 2022, at 18:12, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > So let me try see if I understand by trying to re-phrase > your concern: the operator of a single web server with a > single DNS name and nobody else to help (no CDN, no hoster > no split-mode front-end doing ECH) still has to expose > their name in the cleartext SNI, even if they publish an > HTTPS RR with an ECH public key. > > Is that about right? If so, I agree that's a limitation > of the value one can get from ECH. Yes, this is the occasion I am concerning. Maybe it is wired for you to image someone will publish some website without the help of CDN like Cloudflare. If you live in China, you will find your website will be slow with the the help of Cloudflare, because its edge servers are out of China mainland. > I think Chris' answer wrt encrypting ALPNs etc is correct, > the ECH mechanism does still provide a (perhaps minor) > benefit in such cases, and as Ekr says, a client could send > a bogus SNI in clear in such a case and things should still > work fine if the client gets the right ECH public key. There is no disagreement about other Client Hello Data encrypted by ETH. It always benefit. I am wandering if a client could send a bogus SNI. Because the outer SNI is used to finish another TLS handshake, and the client-facing server also needs a SSL certificate for the outer SNI. How could the client send a bogus SNI? > Perhaps it could be worthwhile exploring that last point a > bit more than the WG has, with a goal of helping get to the > point where turning on ECH could be the norm when putting > up any web server, just as interacting with LE is now? > > I'm not sure that it'd be feasible to depend on DNSSEC in > such cases to handle mismatched ECH public keys though. Depending the DNSSEC maybe not a practical idea, because it is too complicate. But if the DNSSEC has been deployed widely, could we still need the outer SNI any more? What we real needs here is something like a trust anchor. We needs the outer plain text "public_name" just because it is there. If DNSSEC is not an option, what about publish another ECHConfig signing key by DNS. And this key will be changed more slowly than ECHConfig. If the client use some outdated configs, the client-facing server just responds the latest configs with additional signature. And the client could verify them. > There's also a problem that if some clients GREASE ECH but > real uses of ECH don't have the real DNS name as the outer > ClientHello SNI, (e.g. the name.invalid case), or make use > of the published ECH config_id, one could easily distinguish > real uses of ECH vs. GREASE cases which seems a bad outcome > too. This is why we should not depend a real domain name in the outer SNI. We could randomly generate some domain like c01e7ce0b61c6b1e8f5f3392a306a847.com <http://c01e7ce0b61c6b1e8f5f3392a306a847.com/> and use it as the config_id. It just looks like a real .com domain, but there is no need, and will never be registered. It is just a config_id looks like a domain name. As it is a fake domain name, we cannot get a valid SSL certificate. But it does not matter, if we do not depend the outer TLS handshake to "correct" the client's outdated ECHConfig. As I mentioned early, we could publish some signature key with ECHConfig, but the signature key do not need to rotated so frequently like ECHConfig. Because this signature key only used when the client has some outdated ECHConfig. In this occasion, the server signed the new ECHConfigs, and send them to the client. The client verify them with the signature key published by DNS. It seems works. > I could envisage us trying to provide some guidance for such > a scenario (maybe like; servers: don't rotate your ECH public > key and do enable ECH trial decryption, clients: use a random > config_id when not GREASEing if outer SNI == inner SNI). And > I guess that might help a bit to move the overall ecosystem > towards ECH being the norm, even if the operator of that > isolated web server won't get much real benefit from ECH. Maybe we can define a very simple case. In this case, there is only site on one IP address, and there is only need one ECHConfig. So the client does not need to send a config_id and SNI. When the server receive the encrypted client hello, it use the default ECHConfig to decrypt. And if it failed, it respond the new ECHConfig with some signature, which will be verified by some additional
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
