Hi, Ben,
> On Oct 13, 2022, at 22:35, Ben Schwartz <bemasc=40google....@dmarc.ietf.org>
> wrote:
>
> On Thu, Oct 13, 2022 at 8:58 AM Marwan Fayed
> <marwan=40cloudflare....@dmarc.ietf.org
> <mailto:40cloudflare....@dmarc.ietf.org>> wrote:
> ...
>> There are really only two ways to populate the outer-SNI. One way is a
>> fixed name that easily identifies the content operator, e.g.
>> ‘operator-ech.com <http://operator-ech.com/>’. In that case, the number of
>> packets with the fixed
>> outer SNI is sufficiently extraordinary as to either or both:
>> (a) visibly identify the operator, in which case the trade-off for
>> client privacy is operator exposure; and
>
> This is incorrect: the operator is already identified unambiguously by the
> destination IP address, so nothing new is "exposed".
>
>> (b) make it trivially easy for ECH to be blocked, thereby severing
>> many clients from the operator, and the Internet entirely if all
>> operators deploy.
>
> Per the above, I do not believe ECH has any effect on this. The hypothetical
> "blocker" here can easily block all access to a given operator whether or not
> ECH is in use.
I think it really does.
Without ECH, the blocker could only block some sites indicated by SNI. But with
ECH,
the blocker can no longer distinguish the "good" site or "bad" site. They have
no choice but to block the entire
operator if two much "bad" content serving by one operator.
>
>> This is an ‘anti-goal’.
>>
>> Alternatively, the operator generates a random outer-SNI for each DNS
>> query
>
> This would not have any effect on the ability of the hypothetical "blocker"
> to block all access to any operator that it knows is using ECH, so there's no
> reason to do this. It would also break the ECH mismatch fallback mechanism,
> which requires that the operator hold a valid certificate for the outer SNI.
It depends.
If we use a real random fake domain like d0bb72000439acb2.com without any
A/AAAA record,
the blocker may detect the ECH by sending a simple DNS query.
But what if we randomly choose a real domain from the list of all .com/.net
with A/AAAA record,
the blocker can not distinguish ECH any more.
Besides, even one outer-SNI is blocked, the operator could choose another one
easily and quickly.
Actually, the operator should rotate the outer-SNI as they rotating ECHConfig.
The real problem here is that the current design of ECH mismatch fallback
mechanism requires
the operator hod a valid certificate for outer SNI. And it prevents the
operator randomly choose
a real domain, and they have to use a fix domain, which makes the blocking very
easily.
I have proposed two solutions, both don't require a valid certificate as trust
anchor.
One solution is depending the DNSSEC. When the client-facing server need to
correct the client,
just response the new HTTPS records with DNS Signing Key, and the the client
need to verify the
new records by DNSSEC.
In my opinion, this is the most graceful design, and it makes the DNSSEC as the
only trust anchor.
However, maybe it is hard to promote the deployment of DNSSEC verification in
the client side.
So another solution is that we could expose another long-lived signing key as
trust anchor in ECHConfig,
which will not be rotated with the ECHConfig. Every time the server needs to
correct the client, just send
the retry_configs with signature.
I think this is just a transitional solution, because we will reinvent
something DNSSEC has invented.
All in all, neither solution depends a TLS handshake. It seems a litter weird a
protection to SNI need
another SNI without protection.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
