Hi, Eric, Thanks for offering the detailed design considerations.
> On Aug 24, 2022, at 23:08, Eric Rescorla <e...@rtfm.com> wrote: > > 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. The signing key may be lost. But the certificated may be lost as well. Worse more, the operator may set some wrong A/AAAA record. All of this mistake will make the server inaccessible. The draft's do not have any benefit than the signature one for the losing occasion. > 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. I can't agree with you. If we do not use the fake domain, we have to use some common shared domain, maybe offered by Cloudflare or other cloud service. Only set a small domain blacklist can the censors block all the traffic using ECH, which is more worse than my proposal. This is why I propose drop the common shared domain, and use some random generated fake domain instead. The censors could check whether the domain in SNI is existing, by means like whois lookup. But it is not an easy task, because it needs to intercept all TLS handshake and waiting for the whois lookup result. This method is hard to scale, and even impossible for national level traffic censorship.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
