Hi all,
* I don't think there is much ECH spec can do about this - versatility of public name construction depends on many internal operational details of the hosting service. Don’t agree. It is possible. Just introduce 2 stages for adoption: 1. Stage 1: TLS extension that makes no any harm for censors. Add nested InnerHello header, just populate it with encrypted nonce (computer name + time may be enough). Censors are lazy, they would not block it because it does not produce immediate problem for them. 2. Stage 2: Monitor the InnerHello header adoption. After it would reach 90+%, activate the real SNI inside InnerHello. By the way, do not make a mistake to populate original SNI with the special DNS (it is assumed by the current spec), put there some random (but real) DNS name. * The ECH draft specifies a greasing mechanism that achieves exactly that. Clients can insert an ECH extension with fake values -- but only the client and the front end server know it is fake. The on-path attackers cannot tell -- they just see an ECH extension with a bunch of random bytes in it, which is not different from an ECH extension with encrypted data in it. If they block these packets, they are going to block way more that their desired targets. Maybe I was not careful enough, I have not found it in the draft. Moreover, the article from CloudFlare stress that they would reserve a special DNS name (to make life of censor easy). Hence, CloudFlare has read the spec not careful too. Strange, right? I need to repeat again: you currently provision 2 mechanisms for censor’s filtering: 1) new header in the hello packet. 2) clear DNS name in the original SNI to point that it is “evasion”. The first one is an objective problem that needs something special (like 2-stage feature introduction). The second one is just an IETF/TLSWG mistake. Please, clearly specify that original SNI should become finally random DNS name (it should be real one!). * You assume that the censorship will be deployed before the next browser versions are deployed, and that a browser that systematically grease the ECH extension would become immediately unusable. But blocking new versions of browsers will be very costly for the censor -- users do want the security, features and bug fixes of the new versions. We have no evidence of that happening yet. Censors do not care about security. The only thing they care is the full country isolation from the internet. Up to 10% of population temporary isolation from the Internet – is an acceptable trade-off for them. 2 stage feature introduction is mandatory to rise harm from X% to 90%. Ed/ From: Yaroslav Rosomakho <yrosoma...@zscaler.com> Sent: Saturday, November 16, 2024 5:48 AM To: Christian Huitema <huit...@huitema.net>; evasi...@yandex.ru Cc: Raghu Saxena <poiasdpoi...@live.com>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Re: TLS against censorship Christian, I believe the issue that we are currently observing with "blocked ECH" is specific to how public SNI is constructed. A given CDN uses a certain pre-defined public name for all ECH enabled resources - hence an inline filtering party that wants to prevent ECH can match on that specific public name and presence of ECH extension in ClientHello. Ed, I don't think there is much ECH spec can do about this - versatility of public name construction depends on many internal operational details of the hosting service. On top of that, public SNI is used by some intermediaries to perform their own DNS lookup and replace destination IP. This is often done to optimise traffic routing by cloud security providers as the closest CDN node from cloud security provider perspective could be different than the one resulting from client DNS lookup. It is also a technique to prevent certain kinds of domain fronting attacks without invasive TLS inspection. Hence, replacing public SNI with a random string that would not be resolvable to the correct destination is likely to create another set of access issues. Best Regards, Yaroslav On Sat, Nov 16, 2024 at 2:12 AM Christian Huitema <huit...@huitema.net <mailto:huit...@huitema.net> > wrote: On 11/15/2024 9:57 AM, Raghu Saxena wrote: > Hey Ed, > > On 11/16/24 1:08 AM, evasi...@yandex.ru <mailto:evasi...@yandex.ru> wrote: >> Actually, it is not a problem for them, not at all. >> As I stated in the message that you did not copy in the quote: they >> would filter out any Hello that has nested InnerHello. >> It is pretty automatic solution. As soon as implemented on DPI, this >> feature would not need any configuration or manual intervention. >> Only people that upgraded their browser would be punished (not the >> whole population) - they would have to look how to downgrade the >> browser or disable feature. > > Well yes, any new TLS extension can be directly blocked by DPI if they > want. I think practically the best way around such stuff would be to > use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy. Ed, This issue was flagged from the beginning of the SNI/ECH effort. Having a specific TLS extension makes the usage of ECH stand out. But on the other hand, it is pretty difficult to design an ESNI/ECH extension that does not standout, is compatible with standard TLS processing, and is not subject to attacks -- like for example replay attacks. Instead of trying to have ECH engineered to be discreet, the WG picked a design with robust engineering, and then argued that "you do not stand out if everybody does it". Suppose that every TLS Client Hello contains an ECH extension, whether they want to encrypt the SNI or not. If we had that, then your hypothetical censor would have to block every TLS connection, and that would be a very hard choice. The ECH draft specifies a greasing mechanism that achieves exactly that. Clients can insert an ECH extension with fake values -- but only the client and the front end server know it is fake. The on-path attackers cannot tell -- they just see an ECH extension with a bunch of random bytes in it, which is not different from an ECH extension with encrypted data in it. If they block these packets, they are going to block way more that their desired targets. You assume that the censorship will be deployed before the next browser versions are deployed, and that a browser that systematically grease the ECH extension would become immediately unusable. But blocking new versions of browsers will be very costly for the censor -- users do want the security, features and bug fixes of the new versions. We have no evidence of that happening yet. -- Christian Huitema _______________________________________________ TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org <mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
