On Wed, Mar 13, 2024 at 8:49 AM A A <tom25...@yandex.com> wrote: > I think we should change outer SNI randomly and periodicity (e.g 1 hours), > if it change fast enough, censor will need to pay a price to block it, >
This won't work because the public_name is part of the recovery mechanism for misconfiguration, which means that the server needs to have a valid certificate with that identity. -Ekr > > 13.03.2024, 23:40, "Amir Omidi" <amir=40aaomidi....@dmarc.ietf.org>: > > I'd like to understand how the behavior of the latest draft will be under > an adversarial condition. > > One of the things that really excited me about ESNI back in the day was > effectively making it near impossible for countries, like my home country > Iran, from being able to effectively censor the web. AFAIK Iran's main > censorship mechanism revolves around looking for ClientHello's and then > sending a TCP reset when that SNI matches a censored domain. > > I'm wondering, are we losing that ability from ESNI with this plain text > field? Maybe there can be an understanding in the RFC that the client may > omit, or falsify this plaintext field for a bit of extra adversarial > security in these circumstances? > > On Wed, Mar 13, 2024 at 11:26 AM Eric Rescorla <e...@rtfm.com> wrote: > > > > On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena <poiasdpoi...@live.com> > wrote: > > On 3/13/24 14:51, Watson Ladd wrote: > > > I'm not sure what problem you want us to solve here. In the case of > > server offering a single domain, an attacker can determine that > > connections to that domain go to the server and cheaply block based on > > IP. As a result the threat model is one of distinguishing between > > connections to two different inner names. > > An IP can be cheaply recycled as well, for instance restarting a VPS on > a cloud provider. Furthermore, IP based blocking may even be discouraged > at a higher level, for the exact reason that IPs can change pretty > easily. As an operator, I might be able to migrate my hosting to a new > server provider (and hence IP) trivially, but informing my users of a > domain change is much harder. > > > Yes, but the attacker can easily learn these IPs merely by querying > the DNS. Moreover, they can learn the associated domains by sending > a CH with no SNI at all and seeing what's in the certificate. > > > > DNS does not propagate atomically with webserver configuration > > changes. It's thus necessary to deal with mismatches. > While this is true, if there is a configuration mismatch (and hence ECH > cannot work), why is the decision made for the server to transparently > "downgrade" it to non-ECH, instead of sending some kind of alert that > signifies the client to retry without ECH? > > > Three reasons: > > 1. Such an alert would be insecure because an attacker could forge it, > thus causing the client to send ECH in the clear. > > 2. It allows the server to be completely ECH unaware rather than needing > to special case an ECH alert. > > 3. It allows the server to securely provide a new ECHConfig. > > -Ekr > > > > Regards, > > Raghu Saxena > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > , > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
