> On Aug 25, 2022, at 04:00, Eric Rescorla <e...@rtfm.com> wrote: > > On Wed, Aug 24, 2022 at 8:36 AM 涛叔 <h...@taoshu.in <mailto:h...@taoshu.in>> > wrote: >> >>> On Aug 24, 2022, at 23:08, Eric Rescorla <e...@rtfm.com >>> <mailto: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.
What I want to say here is that, if we lost something, we need time to recover. We can issue a new certificate with the same name, but it will take some time to deploy. If the provider is not as big as AWS or Cloudflare, they may do not won PKI. Issuing may take time, as well. >>> 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. Actually, the censors has blocked IP address since the birth of the Internet. However, blocking IP addressed is not as efficient as block domain, because IP addresses are for machine, and can be easily changed, while the domain is for human. We can not address the IP block problem by ECH only. But we could make the situation a little better. If we want to hide the domain, just do it as much as possible. > >> 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. I do not think censors will do it. If they build a domain whitelist for the whole Internet, how do they update their database timely? I think they can only update the database periodically, which will make all new registered domains not work for a while. > 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. They can always do such block, whether or not there is ECH. And let me make another summary again. The key difference of my proposal vs the current draft is how to send some trust retry_config to the client. The current draft reuse the TLS handshake, because it already there. As a result, the draft requires a real additional domain name and a real certificate. If every website has their own additional domain name, there is no different between the out SNI one and inner one, which will broke the SNI protection. As a result, the current draft require websites join some anonymity set and share a common public_name. This design is going to make the Internet more centralized. And if some website do not want to join such pool, they can almost not protect their domain, because they have to set another domain for the public_name. In order to address this problem, I proposed another method to send the trust retry_config, using DNS to public some signing key, instead of utilizing the existing TLS handshake. Of course, it is not a prefect design, neither the draft be. With this proposal, we do not need the outer TLS handshake. As a result, no certificate and domain are required any more. In order to promote the deployment of ECH, we do not want censors distinguish the ECH traffic. So we need some guises. One of which is fill something like a real domain name in the outer SNI. The current draft require some real and common used domain, which will make the Internet more centralized. And my proposal require some random fake domain. It only be used as a id for the protected inner domain. It looks like a domain, but not a real one. If you want, you can register a real one and use it. But a real domain is not required! Every website can use anyone as long as this fake domain name is unique in one anonymity set. If the censor blocked the service by the public_name, just generate a new one. Even though my proposal cannot eradicate the traffic censorship, it works a bit better than the draft and it make censor harder. All in all, I strongly propose the ECH do not depend another TLS handshake. But why? Here is my another undisclosed ambition, a PSI free Internet. We use TLS to protect our communication. The TLS depends the PSI. It is expensive to deploy HTTPS before the emergency of free CA like Let's Encrypt. Maintaining the PSI is not an easy task. If we want to negotiate, we have to let the server choose the responding certificate, which is why the Server Name Indication (SNI) extension is needed. Without the SNI, we cannot establish the TLS, so we cannot encrypt our data. We need some plain text like SNI/ALPN to bootstrap the TLS session. We are not satisfied with this situation, want want to encrypt everything including SNI/ALPN. This is why we design the ECH. The ECH initially only protect the SNI, and then encrypt the whole ClientHello message. Our goal is evolving. When I read the ECH draft, I realized we are trying to building a new standard to safely exchange message without the help of TLS. If we can realize this idea, we do not need PKI for most occasion. If the ECH does not depend TLS, we can not only use it exchange the SNI/ALPN, we can also use ECH to exchange something like public key of (EC)DHE_PSK. The client and server can negotiate a common shared key to encrypt the traffic. Please make your comments. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
