Re: [TLS] Working Group Last Call for ECH

On Wed, Mar 13, 2024 at 2:15 AM Raghu Saxena <poiasdpoiasd@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
>