On Wed, Aug 24, 2022 at 5:00 AM 涛叔 <h...@taoshu.in> wrote: > > On Aug 24, 2022, at 18:12, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > > > 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? >
This would simply cause the correction mechanism not to work. 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? > I think so. You need a mechanism which is tied to the anonymity set and not the specific user. 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. > It's not clear to me that this is better: 1. It means that there is only one anonymity set for a given IP because you don't know what key to sign with otherwise. 2. If you misconfigure the key -- rotation is not the only issue -- then you are completely bricked, which is what the current design was designed mostly avoid. -Ekr >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
