On 11/15/2024 9:57 AM, Raghu Saxena wrote:
Hey Ed,
On 11/16/24 1:08 AM, 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
To unsubscribe send an email to tls-le...@ietf.org
