Andrew, Many thanks. Notewell was never in doubt! Of course it never hurts to be reminded.
Best, --marwan On Tue, 18 Oct 2022 at 13:10, Andrew Alston - IETF <andrew-ietf=40liquid.t...@dmarc.ietf.org> wrote: > > 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 <tls-boun...@ietf.org> 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 goals, but these points matter for > deployment considerations, as described below. > > -------------------- > 2. Server-side > > First, reiterating a point that in the absence of fixed outer-SNI, IP > does *not* reliably identify operators (see Appendix); also where an > IP is provably attached to an operator, without fixed outer-SNI there > are levels of indirection and effort needed to make the association > visible. > > 2A. > Server-side considerations fall in two buckets: An operator manages > authoritative DNS for a zone/domain, or it does not. Consider the > former. An operator has an IP on which half of names are ECH-enabled > and half are not. If IP blocking is easier and more likely, then an IP > block triggered by ECH penalizes non-ECH connections. This is not only > unintended by ECH, but is an "over-reach" of the idea that outer-SNI > is inconsequential b/c IP blocking is easier. > > Now extend that notion out to the large-scale operators that manage > their own DNS and that advertise tens, thousands, or more of IPs, > each having some-to-all names that are ECH-enabled. This is the ideal > setup for ECH. Recall that the outer-SNI is fixed for all domains and > IPs. Since the claim is that IP blocks are easier than SNI blocks > (because the claim is of course true), then notions of “easier to > block by IP” is worse than inconsequential, and severs large numbers > of clients from large parts of the Internet. Is this really the > argument for “outer-SNI doesn’t matter” ? > > Moreover, consider authoritative DNS that is not managed or owned by > the operator -- a common setup, for example, used by owners of content > for load balancing [5] across multiple IPs at different operators. In > this case, ECH ‘on-by-default’ in TLS stacks injects risk into the > operator’s reachability, because IP blocks are easier than ECH blocks. > This is a risk that the operator cannot control. Are we suggesting > it’s ok for the content owner’s auth DNS to trigger an IP block on IPs > they don’t own, operate, or control, and that would take the other > content on the operator’s IP down with it? This is a risk injected by > ECH because of (at least) the way outer-SNI is deployed, which happens > because of “easier to block IPs” thinking, and is solved only by > disabling ECH in the “open source TLS stacks” on which operators will > rely. > > 2B. > ECH, and specifically deployment of fixed outer-SNI, matters to small > or “bedroom closet” operator deployments, too, because they are > completely left behind. Either they enable and confer (at best) no > additional privacy to clients (see Sections 1., above, and 3., below), > or the small operators move their service to a large operator. We > should be asking if this fits with the IETF Mission Statement and > principles set out in RFC3935 “to make the Internet work better” [9]. > > -------------------- > 3. Client-side. Also re-stating for the wider audience that comments > are not intended for public use outside the wg without discussion or > consent. > > A sincere question: If the goal of ECH is privacy, and since privacy > is variable according to the size of anonymity set, how does this > *safely* get deployed to clients? In particular, how does the client > or user know the level of privacy for a given connection? > > Explanation: The anonymity set for a domain cannot be known from a > query and, since IPs can change [2, 3, 5], knowing the anonymity set > requires a client to be aware of all DNS responses for all zones at > all moments in time -- which of course is infeasible, if not > impossible. For example, worldwide DNS queries for all zones in the > .com, .org, .info., and .net zone files in August 2022 revealed that > 43% of names map to a single unique IP that is not shared with other > names [10] -- but that is only four zone files, in one moment in time, > from one vantage point on each of five continents, so lots could be > different today or elsewhere. > > If the outer-SNI is about privacy, should users know how much privacy > they’re getting? (I note that fixed outer-SNI on Twitter or Facebook > arguably provides little more privacy than a bedroom closet.) > Alternatively, if the goal of outer-SNI is censorship circumvention > (and ignoring that this is a no-op for many operators), then does the > outer-SNI create a false (and unrecognized) sense of privacy that puts > clients or users in vulnerable populations at risk? > > Here, too, RFC 3935 arguably compels consideration. The mere existence > of these questions implies that there are design and deployment > considerations attached to outer-SNI that impact clients. These may or > may not violate the stated goals, but there should be at least > acknowledgement, if not consensus. > > -------------------- > 4. Possible next steps? > > Honestly, 'next steps' is the reason to post to the list! At a > minimum, I humbly suggest that opportunities be made to discuss at > 115. There is a direct link between outer-SNI and deployment, not > least that is affected by ECH design goals. > > I defer to the wg to decide the ‘how’ of that discussion, but I humbly > suggest that it should absolutely be within the framework of the tls > wg (RFC3935). > > Thanks for consideration, especially given the nature of the content. > --marwan > > -------------------- > References (also for Appendix) > > [1] RFC791, Internet Protocol, https://www.rfc-editor.org/rfc/rfc791 > (2.3 and beyond) > [2] Fayed et al., “The ties that un-bind:...” ACM SIGCOMM’21, > https://doi.org/10.1145/3452296.3472922 > [3] “The ties that un-bind:...,” 12-min video, > https://youtu.be/zg6944L-B3M?t=2137 > [4] ICANN, WHOIS Accuracy, https://whois.icann.org/en/accuracy > [5] RFC 1794, “DNS Support for Load Balancing,” > https://datatracker.ietf.org/doc/rfc1794 > [6] Henning Schulzrinne, “Networking: The Newest Civil Engineering > Challenge,” https://youtu.be/5lvXIqI_mQ4?t=1435 (direct link to “With > impact comes responsibility” > [7] Das et al., “Anonymity Trilemma:..,” IEEE S&P’18 (Oakland), > https://doi.org/10.1109/SP.2018.00011 > [8] IETF Mission and Principles, https://www.ietf.org/about/mission > [9] RFC 3935, “A Mission Statement for the IETF,” > https://datatracker.ietf.org/doc/rfc3935 > [10] Work in preparation; discussable in a closed forum. > > -------------------- > Appendix (also begging forgiveness in advance for the rather strong > tone for what follows). > > On one very and immediate technical matter, there needs to be absolute > clarity: Each and every claim that bolsters ECH by relying on IP as > identity is a fallacy. This position is easily proven, unequivocal and > wholly defensible. With no effort, there are (at least) three ways to > make this point. > > A1. > Arguments that dismiss concerns about outer-SNI using IP are a logical > fallacy, as follows: > (i) Blocking IPs is bad because “IP is not identity”. See RFC791 [1] > which makes clear that IPs have no relationship with what’s behind > them, more recently Addressing Agility [2, 3] and beyond. Throughout, > this notion is either explicit, or understood to be true, and is > factually correct -- and is the basis of IP blocking being bad. > (ii) In ECH, outer-SNI is dismissed as identifying operators is said > to be inconsequential because “IP is identity.” > (iii) It is not possible for (i) and (ii) to both be true, and (i) is > most definitely true > > Ergo (ii) must be a fallacy. Our suggesting otherwise as a community > sacrifices credibility. > > A2. > IP addresses do not uniquely nor reliably identify an operator, nor > use of the IP. IPs are borrowed, leased, loaned, and passed around, > often without any public record. Some operators have BYOIP products, > in which owners of IP space provide LoAs to operators to advertise > that IP space -- which may or may not terminate with the operator. > Alongside, WHOIS records are known to be inaccurate [4]. Furthermore, > any assumed use of an IP address sets up the assumption for failure. > IP addresses can change for any reason at any time [2,3]. Each of > these statements is true whether an operator owns the IPs on which ECH > is deployed, or not. > > ========== End of Appendix, and post ========== > > _______________________________________________ > TLS mailing list > mailto:TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > Internal All Employees _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
