Hi Marwan,
While refraining from commenting on this point on the body of your email, I do
feel compelled to remind that all postings and contributions are covered by the
notewell at https://www.ietf.org/about/note-well/
Specifically:
• As a participant in or attendee to any IETF activity you acknowledge that
written, audio, video, and photographic records of meetings may be made public.
Thanks
Andrew
From: TLS On Behalf Of Marwan Fayed
Sent: Tuesday, October 18, 2022 3:01 PM
To: tls@ietf.org
Subject: Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
Folks,
A personal opening set of words for the public audience: The comments
below are not for public use outside the mailing list without
discussion or consent; it would be far too easy to take these words
out of context for use by special interests.
A big thanks for the thoughtful replies. The contents of this thread
so far suggest that the design of ECH, and specifically the outer-SNI,
either strongly affects or is strongly affected by deployment matters.
I claim that outer-SNI and deployment are entwined and cannot be
disentangled.
The design of outer-SNI makes assumptions and/or has dependencies, and
with details that are subtle. We might claim that deployment matters
are separate and independent, but that cannot be true if there are
logical and direct technical effects on or by servers, clients, and
the Internet that connects them. "I claim" that the community is both
professionally and ethically obliged [6] to consider deployment
matters. Also within the bounds of IETF, arguably any wg charter is
supplemented or superseded by the IETF Mission Statement and
Principles in RFC3935 [8, 9] that, in context of this thread, is full
of statements that compel consideration of deployment matters.
Permit me to be direct: There are sound technical reasons that the
current design of outer-SNI may achieve the exact opposite of what ECH
sets out to do and/or, quite possibly, that outer-SNI has an adverse
effect on the health of the Internet ecosystem. As a motivating
opener, the technical community lives and breathes notions of
“everything has a trade-off” and “nothing comes for free.” In that
spirit, I note that the challenges faced by the original ESNI in 2018
have not disappeared; at best, outer-SNI has shifted challenges from
‘middleboxes’ (although not entirely) to the clients and servers at
the endpoints. Those trade-offs and impacts should at least be
acknowledged, if not actioned.
So, first technical point: Each and every claim that bolsters ECH by
notions of “IP is identity” is a logical fallacy or factually
incorrect, and is duly ignored. For the purpose of illustration,
expansions and explanations are provided in 'Appendix' trailing this
post. However, it is of course true that “IP blocking is
easier/cheaper than SNI filtering or blocking.” Focussing on
outer-SNI, then, I’ve ‘bucketed’ the deployment details as follows:
1. Reason to revisit: ECH appears to violate the Anonymity Trilemma.
2. Server-side assumptions, considerations, and vulnerabilities.
3. Client-side considerations; inconsistent privacy means misinformed clients
4. Next steps
References
Appendix
1. The Anonymity Trilemma [7] states, “an [anonymous communication
protocol] can only achieve two out of the following three properties:
strong anonymity…, low bandwidth overhead, and low latency overhead.”
If the trilemma exists, and there is no reason to believe it doesn’t,
then it is violated by the ECH. But if and since it is a lemma, it
cannot be violated. So either it is not a lemma, OR ECH doesn’t
violate the lemma directly, which means that ECH must be imposing a
cost, or sacrifices, of one of those properties elsewhere --- and
deserves to be inspected more closely on that basis.
Clearly, ECH is low latency and low b/w overhead, which leaves
anonymity. Note that privacy in ECH is achieved via an anonymity set
of domain names -- not of clients nor operators. In effect, privacy is
conferred on clients by ‘proxy’ of the outer-SNI. If the lemma is
true, then the gained or perceived privacy must be ‘paid’ by some
other means.
Indeed, (i) if an operator is small, or a single IP has few-to-1
domain names, then anonymity doesn’t exist; or (ii) if the operator is
large or there are lots of domain names then anonymity comes at the
cost of the operator’s identity that cannot be reliably assumed or
understood by IP (see Appendix).
I have no wish to make the following statement, especially given the
hard work that’s gone into ECH and that it’s something (certainly I
find) highly desirable, but here goes: On the basis of the lemma, one
could humbly reason that ECH fails to provide privacy as it should be
because it either offers little-to-no more privacy in some cases, or
achieves some level of privacy strictly by always trading operator
identity.
Only the wg can determine whether that means ECH meets, or is unable
to meet, its stated privacy
