Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla <[e-mail]>]

On Wed, Mar 13, 2024 at 8:40 AM Amir Omidi <[e-mail]> 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-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
>>
>