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
