Dear WG, This WG has consensus to work on ECH. Objections like this one with intent to single out individuals are over the line. There is no requirement that anyone answer this email. By participating on the mailing list (and elsewhere) in IETF activities you have agreed to abide by the codes of conduct [0], i.e., we would like to remind everyone to keep the discussion professional on this list.
The Chairs: Joe, Chris, and Sean [0] https://datatracker.ietf.org/doc/rfc7154/ > On Dec 1, 2021, at 18:11, bigtechantitrust > <bigtechantitrust=40protonmail....@dmarc.ietf.org> wrote: > > > Dear Members, > > Disclaimer: The comments herein are my own opinions and are personal > conclusions I’ve arrived at based on simply reasoning things out as I see > them. Any insinuation at motive is purely my speculation, except for my claim > that one person involved admitted that financial motivation was a factor at > his organization, Akamai. That is on the record and archived. I also suspect > that not everyone is responsible and probably most members are being duped > and used as pawns here. > > I’m writing to you with some criticisms of TLS 1.3, specifically ECH. > > Within 5 seconds of analyzing the high-level design of ECH, I knew it was a > horrible idea because it would enable and normalize fully opaque encrypted > connections that even the origin machine administrator could not pry into if > they wanted to. This is done by design, and it is stated so implicitly and > explicitly. > > When I started reading more about the people and organizations behind the > draft, I came across a multitude of articles by some praising their own > efforts and selling the draft hard. Chief among their reasoning was that > “middle boxes are evil”. Right there I knew something nefarious was going on > because the chief proponents are, by definition, middleboxes. So, what they > really mean is “anyone but us are evil.” This immediately stinks of something > that should be the subject of an antitrust investigation, but we’ll come back > to that later. > > Allow me to make clear my criticisms with a simple illustration. > > DoH to get address of middlebox (the Good Guys™, not the bad guys!) -> Opaque > Start ECH -> Opaque > DoH to complete ECH -> Opaque > > As a bonus, the keys swapped over DoH are ephemeral at non-deterministic > intervals, an action that is explicitly described in the draft as a means to > frustrate efforts to glean anything about these connections. > > At the end of the day, even if I were executing smack in the middle of the > network stack in a kernel driver on the origin machine, it is impossible for > me to know anything about this type of connection and this practice has been > normalized, so I have zero discriminators available to me. All I know is > destination IP addresses, which are addresses of boxes that hide the real > destination and data by design. > > Toss in pinned certificates at any point here and the loop is inescapably > closed and 100% opaque to Ring 0. Forget Management Engine, I guess the > working group (or rather the mega corps pushing this through an open > standards body) are the new Ring -1. The cybercriminals who cost businesses > billions of dollars per year and ruin countless lives are going to love this > and they’re on the edge of their seats salivating waiting for you to get this > done and widely distributed. But that’s the point, isn’t it? > > One of the members admitted in an OpenSSL bug ticket (the comments are > preserved in an archive, as they have since been deleted) that there was a > financial motivation to get this draft done within his organization, Akamai. > I believe him, because this entire system is absurd within any other context > and anyone being honest can see that. It’s not to evade surveillance or > censorship from evil regimes (despite that being a claim made by the Akamai > rep), because most of those state actors have already successfully defeated > draft implementations of ECH and its predecessor ESNI and even those that > have not, will with enough time and energy and you know it. > > As an aside, I think we’re all well beyond being hoodwinked with the “but > think of [victim group]!” We’ve mostly all figured out that whenever > corporations, especially corporations run by white people, are screaming > about protecting a minority, they also coincidentally gain money and power in > every such endeavor, like this one. The same company where the rep claimed > ECH was to help homosexuals in the middle east also has dealings with the > Chinese Communist Party, who is actively engaged in genocide and threatening > to erase Japan from the planet with nuclear weapons. > > So, if Akamai is so concerned about activism, maybe Akamai can use their > office in China to stop forced abortions and sterilization of Uighurs, > on-demand murder for organ harvesting and the threat of the extermination of > the Japanese people in their own back yard before they want to push ECH to > get richer uhh err I mean to save homosexuals in the middle east, but I > digress. > > So why march forward? There is only a single reason that makes sense to me to > continue with this draft and I sort of already spoiled the surprise. > > Money. Monopoly. A system like this will nullify virtually all existing > network cybersec technologies as they are today, except for some of the > member’s systems of course. This will conveniently, I’m sure accidently, > expertly create a perfect monopoly on network cybersec, a market the major > proponents are already engaged in and are even actively acquiring companies > that specialize in this field. > > > > Furthermore, ECH will not enhance the privacy of individuals, it will > transfer the privacy of individuals exclusively to the same actors. The > inescapable result is total dominance of the two most lucrative businesses in > the digital space today: data mining and security. > > Go ahead, just start googling “[company] + security or cybersecurity” for > each of the companies that the proponents of ECH in this group represent. > They’re all aggressively expanding and transforming from being middleboxes > into cybersec and big data companies all around the timing of ESNI and ECH. > > What’s worse is that the apparent greed has created a tunnel vision that > entirely fails to consider injured interests that would not be in competition > with the monopoly being created here. > > “Sorry ma’am, your child safety software couldn’t prevent your daughter from > talking with a predator because it couldn’t see that network traffic and > frankly, we have no clue who to even subpoena for records to find her because > the true destination of the forum was 100% encrypted. But hey, isn’t it great > that [identifiable group] can’t be persecuted in [horrible regime territory] > for just being themselves even though this system responsible for protecting > the predator is entirely non-functional in [horrible regime territory]! Gee, > the TLS working group are a bunch of amazing people and society is better > because of them! They thank your daughter for her sacrifice toward a better > world.” > > > > -Some future detective probably > > > > > This draft is irredeemable. Regardless of your motivations, it is entirely > unacceptable to engineer a pillar of the internet in such a way that > completely robs the owner of a device or network to have the ability to glean > any information whatsoever about a connection it hosts. This enables > non-elevated executable code to have more privilege over something on a > device than the kernel itself. This hides more information from the host than > TOR does. That is an abomination. > > I hope that this attempt to use the working group to hard-code special > interest’s business models into the fabric of the internet and create > permanent walled gardens for them will stop now. If not, then I hope the > ensuing antitrust investigations around the world are exceedingly destructive > and sufficiently cleanses open standard groups of actors who would do such a > thing. > > > _______________________________________________ > 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
