On Wed, Aug 24, 2022 at 7:12 AM 涛叔 <h...@taoshu.in> wrote: > Hi, Eric, > > Here is a more detailed proposal. >
Thank you. > > Every server who want to deploy ECH must generate one key pair used for > signature. > > The public key of this signing key pair should be published with the > ECHConfig's public_name. > > The public_name should be a valid, but fake, domain name, which can be > generated randomly, for example, > > c01e7ce0b61c6b1e8f5f3392a306a847.com > > The server operator should not register this domain. The public_name maybe > a real common share > domain. > > The server should store the relation between the public_name and the > signature private key. > Are these keys and names shared between the domains in the anonymity set? When the client try to offering ECHConfig, it must fill the fake > public_name into > the outer SNI field. > This proposal seems to break down here for the single server case because the attacker just needs to read this value out of the DNS and insert it into its block table. And, indeed, if you want to just block ECH entirely, you can largely just block connections with unregistered domains in the outer name. If the client use some outdated ECHConfig to encrypt the inner client hello > message, > the server must respond all new ECHConfigs signed by the key generated > before. > > When the client receive the retry_configs, it will be able to use the > public_key to check > whether these configs are valid. > > While the ECHConfig is rotating, the signature key should not be changed > frequently. > > As long as the signature key not changed, the client will have no problem > to update > their outdated ECHConfig list. > > If we lost or leak the signature key, we need publish a new one. We can > use small TTL > for the signing key. However, the client may have period not access the > server. > This seems pretty undesirable, no? The nominal advantage of the public_name design is that it doesn't create new failure modes: you already have to have valid certificates for the public_name. > By this design, we do not need a real outer SNI domain for a real > handshake to make > sure the retry_configs is valid. > I don't love the public_name design, but it's not really clear to me that this is better. In the multi-domain case it seems like it makes it easier to determine whether ECH is in use, and in the single-domain case, you can just block on the random domain, as above. -Ekr > > On Aug 24, 2022, at 20:50, Eric Rescorla <e...@rtfm.com> wrote: > > > > 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 > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
