On Wed, Aug 24, 2022 at 8:36 AM 涛叔 <h...@taoshu.in> wrote: > 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. >
This is not an issue because you can issue a new certificate with the same name. > Worse more, the > operator may set some wrong A/AAAA record. > Yes, but there are already mechanisms to address this. > 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. > I'll defer further discussion on this topic to those who work more closely with server systems such as David Benjamin or Chris Wood. > 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. > I don't think this adequately reflects the threat model. For large providers, the attacker already knows their IPs and so can block on that basis. What makes ECH viable or non-viable in that case is the attacker's level of willingness to block all the co-domains to the target domains. The public name doesn't change that. 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. > This is not particularly hard to scale. You build a database of every known valid domain (this is not particularly large) and when you encounter a new request you either wait for the lookup or simply terminate the connection until you have looked it up. Moreover, as I mentioned earlier, the attacker can simply record the IP addresses of the offending servers and block those. I have not yet heard you provide a a satisfactory response to that other than that the server can change IPs, but as I mentioned, this is not easy, especially for IPv4, because the old address is now contaminated for some time, so it's not useful for others. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
