Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla <[e-mail]>]

On Wed, Mar 13, 2024 at 8:49 AM A A <[e-mail]> 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=[e-mail]>:
>
> 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-mail]> wrote:
>
>
>
> On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
> ,
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>