Re: [TLS] Working Group Last Call for ECH

[A A <[e-mail]>]

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,

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" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/tls

,

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls" rel="nofollow">https://www.ietf.org/mailman/listinfo/tls