On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi <a...@aaomidi.com> wrote:
> 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? > I don't think it's realistic for a generic client (e.g., a standard browser) to omit or falsify this field. The public_name is necessary to make the recovery mechanism defined in S 6.1.6. It may be the case that there are servers that only have one identity -- though as both Watson and I noted, ECH doesn't provide much value in those cases -- and not care about recovery, but there is no way for the client to know that. With that said, I don't think that anything prevents a server from placing a non-registrable value (e.g., `esni.invalid`) in `public_name`, which has roughly the same impact if people converge on a small number of such names. [0] -Ekr [0] The value must be non-registrable -- or at least controlled by the server -- otherwise an attacker might register it and obtain a valid certificate, thus initiating the 6.1.6 recovery mechanism. > 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
