On Wed, Aug 24, 2022 at 7:48 AM 涛叔 <[email protected]> wrote: > Hi, Eric, > > Thank your for reviewing. > > On Aug 24, 2022, at 22:25, Eric Rescorla <[email protected]> wrote: > > Are these keys and names shared between the domains in the anonymity set? > > > This keys are only used for ECHConfig correction. And the could be shared > across one anonymity set. >
Well, they have to be or it doesn't work. For example, Cloudflare could publish a public key for all site deployed on > it. > > > > 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. > > > The server name in the outer SNI field is not really a valid domain. It > just looks like a domain, > and only used as a id for protected domain when the client's ECHConfigs > are outdated. > Well it's always sent by the client, whether outdated or not, right? So, the attacker can just use it for filtering. All it has to do is look to see if it's a valid registered domain, and if not, drop the connection. > 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. > > > What I propose is drop the certificates for the public_name. Again, in my > proposal, the > public_name is just a id but looks like a normal domain name. There is no > need to register > it and no need to assign some certificate. > Well, the assumption of the public_name design is that it's *already* registered. > 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. > > > There actually no random domain here, it just generated by the server. If > on fake random > domain has been blocked, just generate one. The key point here is that the > random is just > some id to the inner domain. > > The key benefit of this proposal is that the client can verify the > retry_config without the outer > TLS handshake. As a result, there is no need for a real domain and > corresponding cert > are needed. And then, we can fill a randomly generated faked domain. > > As it is only a fake domain, just looks like a real one, every website, no > matter deployed > after a proxy, can choose these fake domain freely. > I'd like to take a step back here. There are two design considerations here: 1. Managing the situation where the server loses its ECH key. 2. Concealing that ECH is in use. The current design is attempting to handle both. It handles the loss of the key by allowing the holder of the certificate corresponding to the public_name to correct the ECHConfig and handles the latter by framing it as an SNI to a valid name, which (hopefully) the attacker is reluctant to block. If we ignore consideration (2), then your design effectively comes down to advertising a public key (or a hash) along with the ECHConfig and using that public key to sign a new ECHConfig. This seems to have potentially better operational properties than the public_name design in ordinary use because you don't need to have a cert for the public_name, but worse properties in terms of recovery because you can still lose the signing key, whereas there are already processes in place to recover certificates for public_name in case you lose all your keys. However, looking at (2) it seems like your design is worse, because the name in the SNI is trivially distinguishable from a valid name (the attacker need only look it up). It's true that it allows for recovery in situations where there is no existing public_name that is not likely to be subject to censorship as part of the anonymity set, but it seems like in that case you could just register one, which would have slightly better properties in terms of SNI detection and fit better into the general design concept, which assumes that you are hiding against that background. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
