Re: [TLS] Working Group Last Call for ECH

[Eric Rescorla <[e-mail]>]

On Wed, Mar 13, 2024 at 9:20 AM Amir Omidi <[e-mail]> wrote:

> > 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".
>

But this will actually cause hard failures for any server which shares an
IP.


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.
>

Yes, because it's not of benefit for websites which share an IP.



> Are there any concerns if this approach is used?
>

There are two questions here:

1. What the specification says
2. What implementations choose to do within the envelope of that
specification.

The specification needs to prescribe a set of behaviors that promote
interoperability, which means that whatever it tells the client to do must
be compatible with what it tells servers to do. Presently, the
specification tells clients to put whatever is in ECHConfig.public_name in
ClientHelloOuter.sni (S 6.1) and tells the server that it may check and
reject it otherwise (S 7.1). We extensively debated whether to forbid
checking in PR #575 and concluded that we should do so. The primary
arguments were the same ones being offered here balanced against the
ecosystem benefits of encouraging the client to correctly populate
ClientHelloOuter.sni to enable the  recovery mechanism. The WG could of
course revisit that decision.

With that said, even if the specification explicitly allowed clients to
omit/falsify ClientHelloOuter.sni, I don't believe that generic clients
(e.g., the kind of Web browsers that most people use) would choose to do
so. The reason is that, as noted above, it would break the recovery
mechanism, and that's more important than the modest increment in
concealing the public_name of servers on non-shared IPs. One might imagine
that some special purpose clients would choose to do so, but that's not the
case I'm talking about.

-Ekr


> On Wed, Mar 13, 2024 at 12:03 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> 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
>>>
>>>