Re: [TLS] Securely disabling ECH
On Tue, Oct 18, 2022 at 8:56 PM Safe Browsing wrote: > The draft does consider this by allowing ECH to be disabled - as discussed > in this thread. Albeit at the cost of an extra round trip. However, the > connection retry logic in the presence of ECH disabling is currently > optional. > > The draft states, in Section 8.2: > “ this may trigger the retry logic” > > It seems this text must change to: > “ this MUST trigger the retry logic” > This language change would not make sense. The context for "this may trigger the retry logic" in section 8.2 offers two options. The sentence structure is "Depending on whether X, this may Y or Z", i.e. if X is resolved one way, then the client does Y, otherwise it does Z. Changing the "may" to "MUST" would result in stating "this MUST trigger the retry logic described in Section 6.1.6 or result in a connection failure", which doesn't really make sense, and wouldn't have the goal you'd like, since a connection failure instead of retry logic would satisfy the MUST. If your server is authoritative for the public name, then the behavior you care about is described in section 8.1. I suspect most implementations of ECH will implement the retry logic, as the misconfigurations and deployment concerns described in section 8.1 are an inevitability, and implementing the retry logic avoids connection failures that would occur without it. I doubt that adding a MUST would make someone more likely to implement the retry logic. > > In order to ensure functional connections in a TLS client agnostic manner, > in the presence of protocol level ECH disabling. > > I would appreciate your thoughts/input. > > On Oct 8, 2022, at 7:41 PM, Eric Rescorla wrote: > > > If you are able to install a new trust anchor, then you should be able to > use the enterprise configuration mechanisms in browsers to disable ECH. > > -Ekr > > > On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing > wrote: > >> Hi Rich, >> >> When I say “authoritative”, I mean it in the true TLS sense, in the way >> that I believe the ECH draft also suggests and requires. >> >> In other words, the middlebox serves a cert to the client that is >> cryptographically valid for the said public name of the client facing >> server. >> >> How can that be when the client facing server guards its private key >> properly? By re-signing the server certificate on the middlebox with a >> private key, local to the middle box only, for which the corresponding >> certificate has been installed in the trust store of the client, before >> sending it on to the client. Only after the original server certificate >> has been validated properly on the middlebox, of course. Message digests >> being managed accordingly/appropriately. >> >> That is a very typical setup for most (all?) TLS inspection devices (next >> gen firewalls and such). >> >> Thus this part of ECH, requiring the middlebox to be authoritative for >> the server, is well understood and prolifically exercised in inspected TLS >> sessions today. What is new is that these connections can now fail/close, >> in the “securely disabling ECH” case, and the onus is on the TLS client, >> not the application, to retry the connection without ECH. >> >> I am after such a client, if one exists already. >> >> Thank you. >> >> Sent from my phone >> >> On Oct 7, 2022, at 11:41 AM, Salz, Rich wrote: >> >> >> >> >> >>- Client <-> *Middlebox* <-> Client-facing server <-> Backend server >> >> >> >>- With "Middlebox" really meaning a middlebox like a firewall or >>similar. >> >> >> >> The middlebox is not allowed to modify traffic between the client and the >> server. Doing so would mean that the packets the client sent are not the >> ones that the server received, and the two message digests would disagree. >> (If you think about things, it **has** to be this way, otherwise TLS >> would not be able to provide integrity guarantees.) >> >> >> >>- From the draft, ECH seems to be designed to still allow successful >>TLS connection establishment if the encrypted_client_hello extension is >>dropped from the ClientHello on a conforming middlebox. Provided that the >>middlebox is authoritative for the client-facing server's public name, as >>reported/delivered by DNS to the client. We can assume that this is the >>case here. >> >> >> >> I do not understand what you mean by this. The word “authoritative” is >> used to mean that it has a certificate and keypair and can do TLS >> termination. DNS giving the client a particular IP address is not >> authoritative. It can be confusing because DNS terminology uses >> authoritative to mean that a particular entity can prepare data used for >> DNS responses. But it is not authoritative in the TLS sense. >> >> >> >> I think your questions can be answered with those two overall corrections >> above. If not, please continue the thread. (And feel free to repost from >> your note since I trimmed for brevity.) >> >> >> >>
Re: [TLS] Securely disabling ECH
Hi Eric, Picking up on your (earlier) reply here. Though it would be possible to adjust the setting in browsers (disabling ECH), this is not an ideal/sufficient method of disabling ECH. Some reasons it is not sufficient: - Not all TLS clients are browsers - Not all browsers (or other TLS clients) may implement this ability - In a multi-browser environment it means that it needs to be configured in more than one place, each using a different method of achieving the same (cumbersome) - even worse if there are other, non-browser, ECH supporting clients present for which ECH needs to be disabled It seems therefore that the ideal place to achieve this is within the protocol itself. Making ECH disabling client agnostic. The draft does consider this by allowing ECH to be disabled - as discussed in this thread. Albeit at the cost of an extra round trip. However, the connection retry logic in the presence of ECH disabling is currently optional. The draft states, in Section 8.2: “ this may trigger the retry logic” It seems this text must change to: “ this MUST trigger the retry logic” In order to ensure functional connections in a TLS client agnostic manner, in the presence of protocol level ECH disabling. I would appreciate your thoughts/input. > On Oct 8, 2022, at 7:41 PM, Eric Rescorla wrote: > > If you are able to install a new trust anchor, then you should be able to use > the enterprise configuration mechanisms in browsers to disable ECH. > > -Ekr > > > On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing > wrote: >> Hi Rich, >> >> When I say “authoritative”, I mean it in the true TLS sense, in the way that >> I believe the ECH draft also suggests and requires. >> >> In other words, the middlebox serves a cert to the client that is >> cryptographically valid for the said public name of the client facing server. >> >> How can that be when the client facing server guards its private key >> properly? By re-signing the server certificate on the middlebox with a >> private key, local to the middle box only, for which the corresponding >> certificate has been installed in the trust store of the client, before >> sending it on to the client. Only after the original server certificate has >> been validated properly on the middlebox, of course. Message digests being >> managed accordingly/appropriately. >> >> That is a very typical setup for most (all?) TLS inspection devices (next >> gen firewalls and such). >> >> Thus this part of ECH, requiring the middlebox to be authoritative for the >> server, is well understood and prolifically exercised in inspected TLS >> sessions today. What is new is that these connections can now fail/close, in >> the “securely disabling ECH” case, and the onus is on the TLS client, not >> the application, to retry the connection without ECH. >> >> I am after such a client, if one exists already. >> >> Thank you. >> >> Sent from my phone >> >>> On Oct 7, 2022, at 11:41 AM, Salz, Rich wrote: >>> >>> >>> >>> Client <-> Middlebox <-> Client-facing server <-> Backend server >>> >>> >>> With "Middlebox" really meaning a middlebox like a firewall or similar. >>> >>> >>> The middlebox is not allowed to modify traffic between the client and the >>> server. Doing so would mean that the packets the client sent are not the >>> ones that the server received, and the two message digests would disagree. >>> (If you think about things, it *has* to be this way, otherwise TLS would >>> not be able to provide integrity guarantees.) >>> >>> >>> >>> From the draft, ECH seems to be designed to still allow successful TLS >>> connection establishment if the encrypted_client_hello extension is dropped >>> from the ClientHello on a conforming middlebox. Provided that the middlebox >>> is authoritative for the client-facing server's public name, as >>> reported/delivered by DNS to the client. We can assume that this is the >>> case here. >>> >>> >>> I do not understand what you mean by this. The word “authoritative” is >>> used to mean that it has a certificate and keypair and can do TLS >>> termination. DNS giving the client a particular IP address is not >>> authoritative. It can be confusing because DNS terminology uses >>> authoritative to mean that a particular entity can prepare data used for >>> DNS responses. But it is not authoritative in the TLS sense. >>> >>> >>> >>> I think your questions can be answered with those two overall corrections >>> above. If not, please continue the thread. (And feel free to repost from >>> your note since I trimmed for brevity.) >>> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
On Tue, Oct 18, 2022 at 9:58 AM Marwan Fayed wrote: > 1. At large-operator scale, where SNI is used to block instead IP, > outer-SNI forces 'over-blocking' such that large swathes of the > Internet will be unreachable to many. (I'm purposefully ignoring > IP-specific matters to focus on ECH, itself.) > That seems like what ECH is designed to do, so I don't think you've uncovered a flaw here. You can find arguments along these lines for any kind of encryption. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
Thank you for the followon post. Now I understand what you are saying. I disagree, but at least I understand :) >1. At large-operator scale, where SNI is used to block instead IP, outer-SNI forces 'over-blocking' such that large swathes of the Internet will be unreachable to many. (I'm purposefully ignoring IP-specific matters to focus on ECH, itself.) Perhaps. We don't know what national-scale entities will do. They could block any connection that has the ECH extension in it, allowing sites to be reached as long as "they" know the connecting site, and then fallback to SNI-blocking. I believe such speculation is an idle academic exercise. >2. ECH privacy is directly proportional to operator size, which devalues small operations The only answer to "how to achieve the benefits of ECH" is to 'hide among the herd', which is achieved only via larger operators. An Internet that discourages small operations is not the Internet we value. I completely disagree with the last sentence, for two reasons. First, as Ben has pointed out, if a small site adds ECH it causes no additional loss of privacy as if they didn't implement it. Second, yes, the larger the anonymity set, the more benefit to "hiding." I suppose if you look at things in a particular way, you can say that ECH increases the worrisome trend toward centralization. Oh well. I am treating ECH as a solution, not a building block. Others may disagree. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
Hi Rich, These are great questions, and no problem at all. Admittedly I've attempted to be perhaps too diplomatic, since the topic is sensitive _and_ I'm an unknown to many in the wg. Also thanks to the replies that have come in while composing this reply. [Minor] Fair point on theorem vs axiom, and probably right that I'm treating it as the latter. I suppose I know of no counterexample to the lemma, which is the reason to treat it as a useful reference point. I'm happy to set this aside as a distraction to bear down on the main focus... My own personal _technical_ assessment is that, **at Internet-wide scale**, the outer-SNI (possibly ECH more generally, but that's much harder to assess), cannot be disassociated from a deployment path. Two reasons: 1. At large-operator scale, where SNI is used to block instead IP, outer-SNI forces 'over-blocking' such that large swathes of the Internet will be unreachable to many. (I'm purposefully ignoring IP-specific matters to focus on ECH, itself.) 2. ECH privacy is directly proportional to operator size, which devalues small operations The only answer to "how to achieve the benefits of ECH" is to 'hide among the herd', which is achieved only via larger operators. An Internet that discourages small operations is not the Internet we value. Having said that... ...For the Rest, and more generally: Seeing above I think there is a root cause to all the confusion: We’re treating ECH as a solution to problems when, I think, it is supposed to be just a building block? If that's true, then at least one way forward is to articulate the distinction and how it matters. (A special thanks to the colleague who pointed out this possibility.) For clarity, if ECH is a building block, then perhaps there is a need to specify what that means, what it enables, what might be built on top? But, if we believe ECH is a solution to a problem then ECH’s success depends squarely on deployment models, and every member of this list imagines different deployments. Whether the deployment details are better or worse, right or wrong, they all matter -- which suggests a need to articulate, acknowledge, and address those details. Re-reading the previous paragraph, maybe there is a need for both to happen. (I'm happy to say more, if anything is unclear.) --marwan On Tue, 18 Oct 2022 at 14:23, Salz, Rich wrote: > > >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. > > Marwan, > > I find it difficult to understand the point(s) you are trying to make. Can > you remove the philosophical digressions (such as "there's no reason to think > the anonymity trilemma doesn't hold", or "general health of the Internet") > and provide specific examples of your concern? > > >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. > > This assumes that the lemma must hold. As far as I know, a lemma is a > *theorem* and you seem to be treating it as an axiom. > > ECH talks about "anonymity set" The end of Section 1 seems to explicitly > discuss, albeit in much plainer language that I can follow, the trade-off > that you seem to be discussing above. > > >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 > > If I understand you correctly, this cannot happen unless the operators allow > it, by implementing ECH. If the owner of the zone puts in DNS information, > and load-balances across multiple providers, they will have to either arrange > the keys to be shared across those providers, or *not do that* for some > providers. Are you concerned that example.com may delegate to Akamai and > CloudFlare, for example, and put in ECH keys that will result in some country > blocking other sites because hosted because they see the target IP? > > Sorry to ask you to repeat yourself. But could you do so, in non-academic > language, with fewer words and more concrete examples? > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
On 18/10/2022 16:36, Ben Schwartz wrote: On the topic of smaller hosts: not every IETF specification is equally useful to everyone, and this is fine. ECH provides more benefit when applied to large hosts, but it doesn't_reduce_ privacy for anyone, so it is safe to deploy on essentially any TLS server. FWIW, I consider that smaller sites can benefit to some extent from ECH as it can hide the difference between a WFH employee accessing marketing.example vs. engineering.example. I've no idea if that'd be a thing enterprises might do but they could. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
Hi Marwan, You seem to be concerned that the ECH Public Name might reveal information that is not already disclosed by the destination IP, in cases where the use of a certain IP address by a certain operator is not otherwise known to the observer in question. This is true! In ECH the correct configuration in this case is to assign an unrelated Public Name to each IP pool. This change does not reduce privacy, and avoids revealing a linkage between different IP addresses that are not otherwise visibly linked. If you think this is not sufficiently clear, we can probably add text to the draft describing how to choose good Public Names. On the topic of smaller hosts: not every IETF specification is equally useful to everyone, and this is fine. ECH provides more benefit when applied to large hosts, but it doesn't _reduce_ privacy for anyone, so it is safe to deploy on essentially any TLS server. On the topic of the "anonymity trilemma": this claim does not apply. ECH is not an "anonymous communication protocol" as defined in this paper (or otherwise), as it does not attempt to conceal the user's intended destination from the ECH operator. --Ben Schwartz smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
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 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 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
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
>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. Marwan, I find it difficult to understand the point(s) you are trying to make. Can you remove the philosophical digressions (such as "there's no reason to think the anonymity trilemma doesn't hold", or "general health of the Internet") and provide specific examples of your concern? >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. This assumes that the lemma must hold. As far as I know, a lemma is a *theorem* and you seem to be treating it as an axiom. ECH talks about "anonymity set" The end of Section 1 seems to explicitly discuss, albeit in much plainer language that I can follow, the trade-off that you seem to be discussing above. >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 If I understand you correctly, this cannot happen unless the operators allow it, by implementing ECH. If the owner of the zone puts in DNS information, and load-balances across multiple providers, they will have to either arrange the keys to be shared across those providers, or *not do that* for some providers. Are you concerned that example.com may delegate to Akamai and CloudFlare, for example, and put in ECH keys that will result in some country blocking other sites because hosted because they see the target IP? Sorry to ask you to repeat yourself. But could you do so, in non-academic language, with fewer words and more concrete examples? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 115 Proposal - ECH, server-side deploy risks and trade-offs
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
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
Re: [TLS] tls@ietf115: Agenda Topics
Gentle reminder. Cheers, spt > On Oct 12, 2022, at 03:44, Sean Turner wrote: > > The TLS WG will meet at IETF 115. A 2 hour slot that has been scheduled for > Thursday, 10 November 2022, 0930-1130 UTC [0]. The chairs would like to > solicit input from the WG for agenda topics. Please send your agenda topics > request and an estimate for how much time you will need to > tls-cha...@ietf.org. Please note that we will prioritize existing WG items. > Please also review the guidance for TLS WG presenters that can be found at > [1]. > > Cheers, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/meeting/115/agenda-neue > [1] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
