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
