> I don't think it's realistic for a generic client (e.g., a standard browser) to omit or falsify this field.
Why not? From my understanding the issue that happens in this situation is that the website becomes less reliable for these TLS clients? If so, let that be a problem for the client to deal with. All this change would do is something in security considerations along the lines of "to make this protocol more censorship resistant, a TLS client MAY choose to omit, or randomly generate the contents of `public_name`. A TLS Server SHOULD handle these situations gracefully, and not actively reject the client". I do not like the idea of saying "some website can choose to do this". In practice, very few websites will go down that route. Are there any concerns if this approach is used? On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla <e...@rtfm.com> wrote: > > > 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
