RFC 9446

Reflections on Ten Years Past the Snowden Revelations 🦋

okay bestie, this one is RFC 9446 and it's an Independent Submission 💅 It came out in July 2023 and it's marked Category: Informational, which means it's for sharing ideas, not a standard you have to implement. The ISSN is 2070-1721 ✨ The header lists no Obsoletes or Updates, so it doesn't replace or change any other RFC 🫶

The authors are S. Farrell from Trinity College, Dublin, F. Badii from Digital Medusa, B. Schneier from Harvard University, and S. M. Bellovin from Columbia University 👑 Four big brains, four perspectives, one memo 🧚

---

Abstract 🌸

okay so this memo is basically a group of reflections on what happened during and after Edward Snowden released info about the United States National Security Agency (NSA) in 2013 😭 There are four perspectives in here: someone who helped sift through the info so the public could be informed responsibly, a security area director of the IETF, a human rights expert, and a computer science and affiliate law professor 💜

The goal is to give some historical perspective and also suggest which security and privacy challenges the technical community should think about next 🔥 But real talk, these essays don't represent a consensus view. They're just the personal opinions of each author ngl 🙈

---

Status of This Memo 🎀

this doc is not an Internet Standards Track specification. It's published for informational purposes, period 💅

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about whether it's valuable for implementation or deployment 🍓 Docs approved by the RFC Editor are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 ✨

If you want info on the current status, errata, or how to send feedback, check https://www.rfc-editor.org/info/rfc9446 🦋

---

Copyright Notice 🌈

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please review those documents carefully, because they describe your rights and restrictions with respect to this document 📜

---

Table of Contents 🧚

1.  Introduction
2.  Bruce Schneier: Snowden Ten Years Later
3.  Stephen Farrell: IETF and Internet Technical Community Reaction
4.  Farzaneh Badii: Did Snowden's Revelations Help with Protecting
        Human Rights on the Internet?
5.  Steven M.  Bellovin: Governments and Cryptography: The Crypto
        Wars
  5.1.  Historical Background
  5.2.  The Crypto Wars Begin
  5.3.  The Battle Is Joined
  5.4.  The Hidden Battle
  5.5.  Whither the IETF?
6.  Security Considerations
7.  IANA Considerations
8.  Informative References
Acknowledgments
Authors' Addresses

---

1. Introduction ✨

okay so on June 6th, 2013, an article showed up in The Guardian [Guard2013] and it kicked off a whole series of stuff that people now call the Snowden revelations 😭 They described some NSA activities, including secret court orders, secret agreements to get so-called "meta-information" (basically source, destination, and timing of communications), and tapping of communications lines 🫢 The scope was absolutely breathtaking, and it caused a sea change inside the IETF, IAB, and other standards organizations 💀

Now that some years have passed, it feels like the right time to look back. We want to see what the community's actions actually did, where security has gotten better, how the threat surface has changed, what still hasn't improved, and where the community should put its energy next 🌸

Bruce Schneier kicks off this collection of individual essays by taking us back to 2013, recalling what it was like for him and others to report on what was happening, and the mindset of everyone involved 🎀 Next, Stephen Farrell looks at how the technical community reacted, especially the IETF community, plus technical advances and where threats remain 🔥 Then Farzaneh Badii talks about how those advances (or lack of them) affected human rights 💜 Finally, Steven M. Bellovin puts the Snowden revelations into a historical context of secrets and secret stealing that goes back centuries, and closes with some suggestions for the IETF 👑

Readers are invited to think about what impact we as a community have had, what challenges are still here, and what positive contribution the technical community can and should make to the security and privacy of citizens of the world 🌈

-- Eliot Lear, Independent Submissions Editor for the RFC Series 🫶

---

2. Bruce Schneier: Snowden Ten Years Later 🍓

In 2013 and 2014, Bruce wrote a ton about new revelations about NSA surveillance, based on documents Edward Snowden provided. But he also had a more personal involvement 😳

He wrote the essay below in September 2013. The New Yorker agreed to publish it, but The Guardian asked him not to 🙈 It was scared of UK law enforcement and worried the essay would make it look bad. And honestly? Given that UK police raided its offices in July 2014, it had legit reasons to be worried 💀

Now, ten years later, he offers this as a time capsule of what those early months of Snowden were like 🦋

okay bestie, paging through hundreds of top-secret NSA documents is a whole vibe 🫠🔍 you're peeking into a forbidden world that is strange, confusing, and fascinating all at once 🌈 so I flew down to Rio de Janeiro in late August because Glenn Greenwald asked me to come help 🧳 he'd been working on the Edward Snowden archive for a couple of months and had a pile of more technical documents he wanted help interpreting. apparently Snowden also thought bringing me down was a good idea 💅 and honestly? it made sense 🎀 I didn't know either of them, but I've been writing about cryptography, security, and privacy for decades. I could decode some of the technical language Greenwald was struggling with, and I could understand the context and importance of various documents. I've also been publicly critical of the NSA's eavesdropping capabilities for a long time. my knowledge and expertise could help figure out which stories needed to be reported ✨ I thought about it a LOT before saying yes 😭 this was before David Miranda, Greenwald's partner, got detained at Heathrow airport by the UK authorities. but even without that, I knew there was a risk 🥺 I fly a ton (a quarter of a million miles per year!!), and being put on a TSA list, or getting detained at the US border with my electronics confiscated, would be a major problem. so would the FBI breaking into my home and seizing my personal electronics. but in the end, that made me MORE determined to do it 💪 I did spend time on the phone with the attorneys the ACLU and the EFF recommended to me 📞 and I talked it through with my partner, especially after Miranda was detained three days before my departure 💜 both Greenwald and his employer, The Guardian, are super careful about who they show the documents to. they only publish the portions that are essential to getting the story out 🧐 it was important to them that I be a co-author, not a source. I didn't really follow the legal reasoning, but the point is that The Guardian doesn't want to leak documents to random people 🙅‍♀️ they will, however, write stories in the public interest, and I'd be allowed to review the documents as part of that process. so after a Skype call with someone at The Guardian, I signed a letter of engagement 📝 and then I flew to Brazil 🇧🇷✈️ I only saw a tiny slice of the documents, and most of what I saw was honestly kind of banal 😴 the concerns of the top-secret world are mostly tactical: system upgrades, operational problems caused by weather, delays from work backlogs, and so on. I paged through weekly reports, presentation slides from status meetings, and general briefings meant to educate visitors. management is management, even inside the NSA 💀 reading them, I felt like I was sitting through some of those endless meetings the presenters try to spice things up, though 🌶️ presentations regularly include intelligence success stories. there were details about what had been found, how, and where it helped, and sometimes there were attaboys from "customers" who had used the intelligence 👏 I'm sure these are meant to remind NSA employees that they're doing good, and it DEFINITELY had an effect on me. those were all things I want the NSA to be doing 🫶 there were SO many code names 😩 everything has one: every program, every piece of equipment, every piece of software. sometimes the code names had their own code names 🙃 the biggest secrets seem to be the underlying real-world information: which particular company MONEYROCKET is, what software vulnerability EGOTISTICALGIRAFFE is (really, I am not making that one up 💀), and how TURBINE works. those secrets collectively have a code name too, ECI, for exceptionally compartmented information, and it almost never shows up in the documents 🤫 I was chatting with Snowden over an encrypted IM connection and joked that the NSA cafeteria menu probably has code names for the menu items. his response: "Trust me when I say you have no idea." 😳 those code names all come with logos, most of them amateurish and a lot of them dumb 🙈 note to the NSA: take a little of that more-than-ten-billion-dollar annual budget and hire yourself a design firm. seriously, it'll pay off in morale 🎨 every once in a while, though, I'd see something that made me stop, stand up, and pace around in circles 🌀 it wasn't that what I read was especially exciting or important. it was just startling. it changed, ever so slightly, how I thought about the world 🌍 Greenwald said that reaction was normal when people started reading through the documents 🫶 intelligence professionals talk about how disorienting it is living on the inside 🫠 you read so much classified information about the world's geopolitical events that you start seeing the world differently. you become convinced that only the insiders know what's really going on, because the news media is so often wrong. your family is ignorant. your friends are ignorant. the whole world is ignorant. the only thing keeping you from ignorance is that constant stream of classified knowledge 👑 it's hard not to feel superior, not to keep saying things like "If you only knew what we know" all the time. I can understand how General Keith Alexander, the director of the NSA, comes across as so supercilious. I only saw a minute fraction of that secret world, and I started feeling it too 😬 it turned out to be a terrible week to visit Greenwald, because he was still dealing with the fallout from Miranda's detention 😓 two other journalists, one from The Nation and one from The Hindu, were also in town working with him. a lot of my week was Greenwald rushing into my hotel room, handing me a thumb drive of new stuff to look through, and rushing back out again 🏃‍♀️💨 a technician from The Guardian got a search capability working while I was there, and I spent some time with it 🔎 question: when you're handed the ability to search through a database of NSA secrets, what's the first thing you look for? answer: your name 🙈 it wasn't there. neither were any of the algorithm names I knew, not even the algorithms I knew the US government uses 🤷‍♀️ I tried to talk to Greenwald about his operational security 😤 it had been incredibly stupid for Miranda to be traveling with NSA documents on a thumb drive. transferring files electronically is literally what encryption is for. I told Greenwald that he and Laura Poitras should be sending large encrypted files of dummy documents back and forth every day 🔐 once, at Greenwald's home, I walked into the backyard and looked for TEMPEST receivers hiding in the trees 🌳👀 I didn't find any, but that doesn't mean they weren't there. Greenwald has a lot of dogs, but I don't think that would stop professionals 🐶 I'm sure a bunch of major governments have a complete copy of everything Greenwald has. maybe the black bag teams bumped into each other in those early weeks 💀 I started doubting my own security procedures, ngl 😰 reading about the NSA's hacking abilities will do that to you. can it break the encryption on my hard drive? probably not. has the company that makes my encryption software deliberately weakened the implementation? probably. are NSA agents listening in on my calls back to the US? very probably. could agents take control of my computer over the Internet if they wanted to? definitely. in the end, I decided to do my best and stop worrying about it 🫠 it was the agency's documents, after all. and what I was working on would become public in a few weeks 📰 I wasn't sleeping well, either 😴 a lot of it was the sheer magnitude of what I saw. it's not that any of it was a real surprise. those of us in the information security community had long assumed the NSA was doing things like this. but we never really sat down and figured out the details, and having the details confirmed made a big difference 🤯 maybe an analogy helps. everyone knows death is inevitable; there's absolutely no surprise about that. yet it still arrives as a surprise, because we spend most of our lives refusing to think about it 🥀 the NSA documents were a bit like that. knowing it's surely true that the NSA is eavesdropping on the world, and doing it in such a methodical and robust manner, is very different from coming face-to-face with the reality that it is, and with the details of how it's doing it 😵‍💫 I also found it incredibly hard to keep the secrets 🤐 The Guardian's process is slow and methodical. I move much faster. I drafted stories based on what I found. then I wrote essays about those stories, and essays about the essays 📚 writing was my therapy. I'd wake up in the wee hours of the morning and write an essay. but that still put me at least three levels beyond what was published 🌀 now that my involvement is out, and my first essays are out, I feel a lot better 🌸 I'm sure it'll get worse again when I find another monumental revelation, because there are still more documents to go through 🫣 I've heard it said that Snowden wants to damage America. I can say with certainty that he does not 🇺🇸 so far, everyone involved in this incident has been incredibly careful about what gets released to the public 🧤 there are many documents that could be immensely harmful to the US, and no one has any intention of releasing them. the documents the reporters do release are carefully redacted 🖍️ Greenwald and I repeatedly debated with The Guardian editors about the newsworthiness of story ideas, stressing that we would not expose government secrets simply because they're interesting 🙅‍♀️ the NSA got incredibly lucky 🍀 this could have ended with a massive public dump like Chelsea Manning's State Department cables. I suppose it still could 😬 even so, I can imagine how this feels to the NSA. it's used to keeping this stuff behind multiple levels of security: gates with alarms, armed guards, safe doors, and military-grade cryptography 🔒 it's not supposed to be sitting on a bunch of thumb drives in Brazil, Germany, the UK, the US, and who knows where else, protected largely by some random people's opinions about what should or should not stay secret 😱 this is easily the greatest intelligence failure in the history of ever. it's amazing that one person could have had so much access with so little accountability, and could sneak all of this data out without raising any alarms 🚨 the odds are close to zero that Snowden is the first person to do this; he's just the first person to make public that he did. it's a testament to General Alexander's power that he hasn't been forced to resign 👑 it's not that we weren't being careful about security, it's that our standards of care are sooo different 🫠 from the NSA's point of view, we're all major security risks, myself included 🙃 I was taking notes about classified material, crumpling them up, and

🎀 okay so this is where Bruce gets really real about the surveillance life, bestie 😭 He was printing "TOP SECRET/COMINT/NOFORN" documents in a hotel lobby 💀 and once grabbed the wrong thumb drive to dinner, so the unencrypted one full of top-secret stuff got left in his hotel room. Honest mistake tbh, they were both blue 🙈 Like, if he were an NSA employee, that alone would get him fired. No notes. People have written so much about how constant surveillance changes you. When you know someone's watching, you self-censor 😵‍💫 You get less open and less spontaneous. You reread what you typed and replay phone calls in your head, wondering how they'd sound if someone pulled them out of context and judged them from some imaginary observer's POV. You conform more. You kind of suppress your own individuality, and that's the tea. Even though Bruce had been working in privacy for decades and already knew plenty about the NSA, the change still hit him hard 💔 That feeling hasn't faded. He's way more careful about what he says and writes now, way less trusting of communications tech, and way less trusting of the computer industry 🧊

After a lot of back and forth, Greenwald and Bruce agreed to write three stories together to start 📝 All three are still in progress. Bruce also wrote two commentaries on the Snowden documents that had just gone public, and there's a whole lot more coming, because even Greenwald hasn't gone through everything yet 📚

Since his trip to Brazil (one month before), he's flown back to the US once and domestically seven times, and none of it went sideways ✈️ He's not on any list yet. At least, none he knows about 👀

As it happened, Bruce didn't write much more with Greenwald or The Guardian. Those two had a falling out, and by the time things settled and they were both writing about the documents on their own, Greenwald was at the newly formed website The Intercept. Somehow Bruce got cut out of the whole process 💔 He heard Greenwald was annoyed with him but never learned why, and they haven't spoken since 🥀

Still, he's proud of the one story he was part of: how the NSA hacks Tor 🧅 He also considers it a personal win that he pushed The Guardian to publish NSA documents detailing QUANTUM, because he doesn't think that would have come out any other way 🔥 And he still uses those pages today when he teaches cybersecurity to policymakers at the Harvard Kennedy School 🎓

Other people wrote about the Snowden files, and they wrote a LOT ✍️ At first it was a slow trickle, then it turned into a steadier flow. Between Greenwald, Bart Gellman, and The Guardian reporters, there was a steady stream of news. (Bart brought in Ashkan Soltani for the technical side, which was a genius move, even if it cost Ashkan a government job later 🫶) More stories got picked up by other publications too.

It got weird, honestly 😭 Both Greenwald and Gellman held documents back so they could publish them in their books. Jake Appelbaum, who hadn't yet been accused of sexual assault by multiple women, was working with Poitras. He partnered with Der Spiegel to release an implant catalog from the NSA's Tailored Access Operations group. To this day, Bruce is convinced that document was NOT in the Snowden archives, and that Jake got it some other way and it was released with the implication that it came from Edward Snowden 🕵️‍♀️ Bruce thought it was important enough that he started writing about each item in that document on his blog, "NSA Exploit of the Week." That got his website blocked by the DoD, and yes, he keeps a framed print of the censor's message on his wall 🖼️💀

Maybe the most surreal disclosures were when artists started writing fiction based on the documents 🎨 This was in 2016, when Laura Poitras built a secure room in New York to house the documents. By then the documents were years out of date, and now they're over a decade out of date. (They were leaked in 2013, but most of them were from 2012 or earlier.) ⏳

Bruce ended up being kind of a public ambassador for the documents 🎤 When he got back from Rio, he gave talks at a private conference in Woods Hole, at the Berkman Center at Harvard, at something called the Congress on Privacy and Surveillance in Geneva, at events at both CATO and New America in DC, at an event at the University of Pennsylvania, at an event at EPIC, at a "Stop Watching Us" rally in DC, at the RISCS conference in London, at the ISF in Paris, and then at the IETF meeting in Vancouver in November 2013. (He remembers very little of this and is reconstructing it all from his calendar 📅😅)

What struck him at the IETF was the indignation in the room, and the calls to action 📢 And there WAS action, on lots of fronts. We technologists did a lot to help secure the Internet, for example 💪

The government didn't do its part, though 😤 Despite the public outcry, the investigations by Congress, the pronouncements from President Obama, and federal court rulings, Bruce doesn't think much has changed. The NSA canceled a program here and a program there, and it's now more public about defense. But he doesn't think it's any less aggressive about either bulk or targeted surveillance. Its government authorities haven't been restricted in any way, and surveillance capitalism is still the business model of the Internet 🫠

And Edward Snowden? They were in contact for a while on Signal 📱 Bruce visited him once in Moscow, in 2016. He also had Snowden do a guest lecture for his class at Harvard for a few years, remotely over Jitsi. Afterwards, Bruce would hold a session where he promised to answer every question Snowden evaded or didn't answer, explain every response Snowden did give, and be candid in a way that someone with an outstanding arrest warrant simply can't be. Sometimes Bruce thought he could channel Snowden better than Snowden could 🧚

But now it's been a decade 🕰️ Everything Snowden knows is old and out of date. Everything we know is old and out of date too. The NSA suffered an even worse leak of its secrets by the Russians, under the guise of the Shadow Brokers, in 2016 and 2017. The NSA has rebuilt, and it again has capabilities we can only guess at 🫥

---

3. Stephen Farrell: IETF and Internet Technical Community Reaction ✨

In 2013, the IETF and, more broadly, the Internet technical, security, and privacy research communities were surprised by the surveillance and attack efforts exposed by the Snowden revelations [Timeline] 😳 Sure, the potential for that kind of thing was known. But it was the scale and pervasiveness of what got disclosed that was alarming and, honestly, pretty annoying for a LOT of Internet engineers 😤

As for the IETF's reaction: informal meetings during the July 2013 IETF meeting in Berlin showed that participants felt these revelations meant we needed to do more to improve the security and privacy properties of IETF protocols, and to help make sure deployments made better use of the security and privacy mechanisms that already existed 🔐 In August, the IETF set up a new mailing list [Perpass], which became a useful place for triaging proposals for work on these topics 📬 At the November 2013 IETF meeting, there was a lively, very well attended plenary session [Plenary-video] on "hardening the Internet" against such attacks 🎤🔥. It was followed by a "birds of a feather" session [Perpass-BoF] devoted to more detailed discussion of possible actions, like new working groups, protocols, and Best Current Practice (BCP) documents that could help improve things 🦋

Then in February/March 2014 there was a joint IAB/W3C workshop on "strengthening the Internet against pervasive monitoring" [STRINT] in London, attended by 150 engineers. (Still the only IAB workshop Stephen has been to where they needed a waiting list for people once the venue hit capacity! 🙈) The STRINT workshop report was eventually published as [RFC7687] in 2015. Meanwhile, work moved forward on a BCP document codifying the IETF community's view that "pervasive monitoring is an attack" [RFC7258] (aka BCP 188) 🛡️ The IETF Last Call discussion for that short document included more than 1000 emails 😭 Everyone broadly agreed on the overall message, but a number of IETF participants thought putting that message into the RFC Series and IETF processes was controversial. Anyway, the BCP was published in May 2014 🎉 The key statement, the one rough consensus was reached on, is in the abstract of RFC 7258 and says "Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible." That document has since been referenced [Refs-to-7258] by many IETF working groups and RFCs as justification for additional work on security and privacy 💜 Throughout that period and beyond, the repercussions of the Snowden revelations stayed a major, ongoing agenda item for both of the IETF's main technical management bodies, the IAB and the IESG (which Stephen served on at the time) 🧠

So far Stephen has only described the processes the IETF used to deal with the attacks. But there was also a bunch of technical work started by IETF participants that was at least partly motivated by the Snowden revelations 🛠️✨

In November 2013, a working group was set up to document better practices for using TLS in applications [UTA], so that deployments would be less at risk from some of the attacks related to stripping TLS or to applications misusing TLS APIs or parameters 🔒 Similar work was done later to update recommendations for using cryptography in other protocols in the CURDLE Working Group [CURDLE]. CURDLE was, to an extent, created to enable use of a set of new elliptic curves documented by the IRTF Crypto Forum Research Group [CFRG] 🌈 That work was partly motivated by concerns (maybe ultimately unfounded ones) about elliptic curves defined in NIST standards, following the DUAL_EC_DRBG debacle [Dual-EC] (more on that below), where a NIST random number generator had been deliberately engineered to produce output that could be vulnerable to NSA attack 😬

Work on a new version of TLS kicked off in 2014, mainly because TLS 1.2 and earlier implementations had been shown to be vulnerable to a range of attacks over the years 🔄 The work on TLS 1.3 [RFC8446] also aimed to encrypt more of the handshake so that less information was exposed to network observers. That was a pretty direct result of the Snowden revelations 🫶 Work to improve TLS further in this respect is still going today with the so-called Encrypted Client Hello (ECH) mechanism [TLS-ECH], which aims to remove one of the last privacy leaks left in current TLS 🦋✨

Okay so DNS got a glow-up too 💅 Encrypting DNS traffic with DNS over TLS (DoT) [RFC7858] or DNS Queries over HTTPS (DoH) [RFC8484] also started because of the Snowden revelations 😭 Before that, nobody really thought about privacy for DNS data, or (more importantly) for the act of looking up DNS data 🙈 The push to encrypt DNS is a huge shift for the Internet. It cuts down on cleartext, but it also moves the points-of-control, and ngl that part was and still is controversial 🌸 Still, the IETF did its job and defined new protocols that can enable better DNS privacy ✨ Then there's HTTP version 2 [RFC9113] and QUIC [RFC9000], which show the IETF's whole vibe shift toward always-encrypted protocols being the new norm, at least at and above the transport layer 🦋

Not every initiative was a win, though 💀 Trying to define a new MPLS encryption mechanism [MPLS-OPPORTUNISTIC-ENCRYPT] totally flopped because nobody was interested, and the already-deployed IEEE Media Access Control Security (MACsec) scheme was already a thing 😩 Still, there's been a pretty clear trend of trying to get rid of cleartext on the Internet, which is a stepping stone to better privacy when you treat network observers as attackers 🫶

The IETF is just one piece of the broader Internet technical community, and lots of non-IETF stuff got kicked off by the Snowden revelations 🍓 A bunch of that eventually led to new IETF work to standardise better security and privacy mechanisms that were developed elsewhere ✨

Let's talk about 2013 for a sec 🎀 The web was mostly unencrypted even though HTTPS was pretty usable, and that was partly because of problems using the Web PKI at scale. The Let's Encrypt initiative [LE] issued its first certificates in 2015 as part of its mission to move the web toward being fully encrypted, and it has been extremely successful at that 👑 After that, the automation protocols developed for Let's Encrypt were standardised in the IETF's ACME Working Group [ACME] 💖

Email was giving very cleartext energy in 2013 😭 Most email transport between mail servers was unencrypted, which directly enabled some of the attacks in the Snowden documents. Major mail services and MTA software developers put in a ton of work since then, and now more than 90% of email is encrypted between mail servers 🌈 Various IETF protocols were defined to make things even better, like SMTP MTA Strict Transport Security (MTA-STS) [RFC8461] 🧚

MAC addresses were historically long-term fixed values that were visible to local networks (and beyond), which enabled some tracking attacks documented in the Snowden documents [Toronto] 🙈 Implementers, vendors, and the IEEE 802 standards group recognised this weakness and started working on MAC address randomisation. That led to the IETF's MADINAS Working Group [MADINAS], which aims to make sure randomised MAC addresses can be used on the Internet without causing unintentional harm 🦋 There's also a whole history of IETF work on deprecating MAC-address-based IPv6 interface identifiers and advocating pseudorandom identifiers and temporary addresses. Some of that even pre-dates Snowden [RFC7217] [RFC8064] [RFC8981] 💜

So, the summary, bestie 💅 The huge amount of technical work done in the IETF and elsewhere because of the Snowden revelations focused on two main things. First, decreasing how much plaintext stays visible to network observers. Second, reducing the number of long-term identifiers that enable unexpected identification or re-identification of devices or users 🔥 It's not finished, and deployment isn't universal, but real progress has been made, and the work keeps going even if the level of annoyance at the attack has faded a bit over time 🌸

Not everyone was on board, though. The pushback against these improvements in security and privacy, and the changes they cause for deployments, came from more or less two camps. Those whom these improvements force to change tend to react badly, but later figure out how to adjust. Others seemingly prefer not to strengthen security, so that they can keep achieving what they call "visibility," even though many engineers correctly argue that such an anti-encryption approach inevitably leads to worse security overall 🙄

The recurring nature of this drama is nicely illustrated by [RFC1984]. That informational document was published in 1996 as an IETF response to an early version of the perennial "encryption is bad" argument 🍓 In 2015, the unmodified 1996 text was upgraded to a BCP (BCP 200), because the underlying arguments haven't changed and won't change 💅

Looking back on all of this from a 2023 vantage point, I think that, as a community of Internet engineers, we got a lot right 🫶 But today there's way more that needs to be done to better protect the security and privacy of people who use the Internet 😭 In particular, we (the technical community) haven't done nearly as good a job at countering surveillance capitalism [Zubhoff2019], which has exploded in the last decade 💀 Partly that's because many of the problems are outside the scope of bodies like the IETF. For example, intrusive backend sharing of people's data for advertising purposes can't really be mitigated via Internet protocols 🙃

Here's the tea, though ☕ The real annoyance felt about the Snowden revelations is (in general) not felt nearly as much when it comes to the legal but hugely privacy-invasive activities of major employers of Internet engineers 👀

It's noteworthy that RFC 7258 doesn't consider bad actors to be limited to governments 🧚 Personally, I think many advertising industry schemes for collecting data are egregious examples of pervasive monitoring, and hence ought also be considered an attack on the Internet that ought to be mitigated where possible. However, the Internet technical community clearly hasn't acted that way over the last decade 😩

Maybe that indicates that Internet engineers, and the bodies they congregate in, need to put way more emphasis on standards for ethical behaviour than they have for the first half-century of the Internet 🌈 It would be good to see the current leaders of Internet bodies work to make progress there. But at the time of writing, it sadly seems more likely that government regulators will be the ones trying to force better behaviour 🥺 That comes with a significant risk of regulations that stymie the kind of permissionless innovation that characterised many earlier Internet successes 💔

So yeah, we got a lot right in our reaction to Snowden's revelations, but currently we have a "worse" Internet 💀 Still, I do hope to see a sea change, as the importance of real Internet security and privacy for people becomes utterly obvious to all, even the most hard-core capitalists and government signals intelligence agencies ✨ That may seem naive, but I remain optimistic that, as a fact-based community, we (and eventually our employers) will recognise that the lesser risk is to honestly aim to provide the best security and privacy practically possible 🫶

---

4. Farzaneh Badii: Did Snowden's Revelations Help with Protecting Human Rights on the Internet? 🌈

It is very difficult to empirically measure the effect of Snowden's revelations on human rights and the Internet 🤔 Anecdotally, we've been watching dominant regulatory and policy approaches that impact technologies and services at the core of protecting human rights on the Internet. (A range of European Union laws aims to address online safety or concentration of data. There are many more regulations that have an impact on the Internet [Masnick2023].) There has been little progress in fixing technical and policy issues that help enable human rights 😮‍💨 The Snowden revelations did not revolutionize Internet governance and technical approaches to support human rights such as freedom of expression, freedom of association and assembly, and privacy. They didn't decrease the number of Internet shutdowns, or the eagerness of authoritarian (and to some extent democratic) countries to territorialize the Internet 🚩 In some cases, governments argued that they should have more data sovereignty or Internet sovereignty. Perhaps the revelations helped with the evolution of some technical and policy aspects ✨

After Snowden's revelations 10 years ago, engineers and advocates at the IETF responded in a few ways 🦋 One prominent response was the issuance of a BCP document, "Pervasive Monitoring Is an Attack" [RFC7258], by Farrell and Tschofenig. The responses to the Snowden revelations did not mean that the IETF had lost sight of issues such as privacy and surveillance 💜 There were instances of resistance to surveillance in the past by engineers (we don't delve into how successful that was in protecting human rights). However, historically, many engineers believed that widespread and habitual surveillance was too expensive to be practical. The revelations proved them wrong 😤

Rights-centered activists were also involved with the IETF before the revelations 🎀 For example, staff from the Center for Democracy and Technology (CDT) were undertaking work at the IETF (and were a member of the Internet Architecture Board), and held workshops about the challenges of creating privacy-protective protocols and systems. The technical shortcomings that were exploited by the National Security Agency to carry out mass-scale surveillance were recognized by the IETF before the Snowden revelations [Garfinkel1995] [RFC6462]. In 2012, Joy Liddicoat and Avri Doria wrote a report for the Internet Society that extensively discussed the processes and principles of human rights and Internet protocols [Doria2012] 📚

Perhaps the Snowden revelations brought more attention to the IETF and its work as it related to important issues, such as privacy and freedom of expression 👀 They might also have expedited, and helped with more easily convening, the Human Rights Protocol Considerations Research Group (HRPC) in the Internet Research Task Force (IRTF) in July 2015 🧚 The HRPC RG was originally co-chaired by Niels ten Oever (who worked at Article 19 at the time) and Internet governance activist Avri Doria 👑 The charter of the HRPC RG states that the group was established:

"to research whether standards and protocols can enable, strengthen or threaten human rights, as defined in the Universal Declaration of Human Rights (UDHR) and the International Covenant on Civil and Political Rights (ICCPR)." 🌸

Okay so, during the past decade a few successful strides were made to create protocols that, when and if they get implemented, aim to protect users' privacy and help reduce pervasive surveillance 🔒✨ These efforts were totally in keeping with the IETF consensus found in RFC 7258 🫶 Sometimes these protocols have anti-censorship qualities too, which is so iconic. A few examples immediately come to mind: 1) the encryption of DNS queries (for example, DNS over HTTPS), 2) the ACME protocol underpinning the Let's Encrypt initiative, and 3) the Registration Data Access Protocol (RDAP) [RFC7480] [RFC7481] [RFC8056] [RFC9082] [RFC9083] [RFC9224]. (It is debatable that RDAP had anything to do with the Snowden revelations, ngl, but it is still a good example and is finally being implemented 🙈)

The DNS Queries over HTTPS protocol aimed to encrypt DNS queries 🌸 Four years after RFC 7258, DoH was developed to tackle both active and passive monitoring of DNS queries. It is also a tool that can help with combatting censorship 💜 Before the revelations, DNS query privacy would have been controversial because it was either expensive or unnecessary, but the Snowden revelations made it way more plausible 👀 Let's Encrypt was not an Internet protocol, but it was an initiative that aimed to encrypt the web, and later on some of the automation protocols were standardized in the IETF ACME Working Group 🦋 RDAP could solve a long-term problem: redacting the domain name registrants' (and IP address holders') sensitive, personal data while at the same time enabling legitimate access to the information. Main character energy for real 👑 As to the work of the HRPC Research Group, it has so far issued [RFC8280] by ten Oever and Cath, plus a number of informational Internet-Drafts 🧚

While we cannot really argue that all the movements, privacy-preserving protocols, and initiatives that enable protecting human rights at the infrastructure layer solely or directly result from the Snowden revelations, I think it is safe to say the revelations helped expedite the resolution of some of the "technical" hesitations that had an effect on fixing Internet protocols that enabled the protection of human rights 🌈

Unfortunately, the Snowden revelations have not yet helped us meaningfully with adopting a human rights approach 😭 We can't agree on prioritizing human rights in our Internet communities for a host of reasons. This could be due to: 1) human rights are sometimes in conflict with each other; 2) it is simply not possible to mitigate the human right violation through the Internet protocol; 3) it is not obvious for the engineers in advance how the Internet protocol contributes to enabling human rights protections, or precisely what they ought to do; 4) the protocol is already there, but market, law, and a host of other societal and political issues do not allow for widespread implementation. Ugh, it's so messy 💀

IETF did not purposefully take a long time to adopt and implement protocols that enabled human rights. There were technical and political issues that created barriers 🍓 For example, as WHOIS was not capable of accommodating a tiered-access option, the IETF community attempted a few times before to create a protocol that would disclose the necessary information of IP holders and domain name registrants while at the same time protecting their data (the Cross Registry Internet Service Protocol (CRISP) and later on the Internet Registry Information Service (IRIS) are the examples). However, IRIS was technically very difficult to implement. It was not until RDAP was developed and the General Data Protection Regulation (GDPR) was enacted that the Internet Corporation for Assigned Names and Numbers had to consider instructing registries and registrars to implement RDAP, and its community had to come up with a privacy-compliant policy. Overall, a host of regulatory and market incentives can halt or slow down the implementation of human-rights-enabling protocols, and implementation could depend on other organizations with their own political and stakeholder conflicts. Sometimes the protocol is available, but the regulatory framework and the market do not allow for implementation. Sometimes the surrounding context includes practical dimensions that are easy to overlook in a purely engineering-focused argument 🎀

A curious example of this is sanctions regimes that target transactions involving economically valuable assets. As a result, sanctions might limit sanctioned nations' and entities' access to IPv4 resources (because the existence of a resale market for these addresses causes acquiring them to be interpreted as buying something of value), though the same consideration may not apply to IPv6 address resources. But IPv6 adoption itself depends on a host of complex factors that are by no means limited to technical comparisons of the properties of IPv4 and IPv6. Someone focused only on technical features of protocols may devise an elegant solution but be surprised both by deployment challenges and unintended downstream effects 🤯 Sometimes there are arguments over implementation of a protocol because, as it is perceived, while it can protect freedom of expression and reduce surveillance, it can hamper other human rights. For instance, the technical community and some network operators still have doubts about the implementation of DNS over HTTPS, despite its potential to circumvent censorship and its ability to encrypt DNS queries. The arguments against implementing DoH include protection of children online and lack of law enforcement access to data 🙈

We must acknowledge that sometimes the technical solutions we use to protect one right (for example, encryption to protect the right to privacy or to prevent surveillance) could potentially affect technical and policy solutions that try to protect other human rights (for example, encryption could prevent financial institutions from monitoring employees' network activities to detect fraudulent behavior). Acknowledging and identifying these conflicts can help us come up with alternative techniques that could protect human rights while not hampering other technical solutions such as encryption ⭐ Where such alternative techniques are not possible, acknowledging the shortcoming could clarify and bring to light the trade-offs that we have accepted in our Internet system 🫶

Ironically, we advocate for connectivity and believe expressing oneself on the Internet is a human right, but when a war erupts, we resort to tools that impact that very concept 😤 For example, some believe that, by imposing sanctions on critical properties of the Internet, we can punish the perpetrators of a war. The Regional Internet Registries that are in charge of registration of IP addresses have shown resilience to these requests. However, some tech companies (for example, Cogent [Roth2022]) decided not to serve sanctioned countries and overcomplied with sanctions. Overcompliance with sanctions could hamper ordinary people's access to the Internet [Badii2023] 💔

Perhaps we can solve some of these problems by undertaking a thorough impact assessment and contextualization to reveal how and why Internet protocols affect human rights (something Fidler and I argued for [Badii2021]). Contextualization and impact assessment can reveal how each Internet protocol, or each line of code, in which systems, has an impact on which human rights, and whose 🔍

The HRPC RG (which I am a part of) and the larger human rights and policy analyst communities are still struggling to analyze legal, social, and market factors alongside the protocols, so they have a good understanding of what has an impact and what has to be changed. It is hard, but it is not impossible 💪 If we thoroughly document and research the lifecycle of an Internet protocol and contextualize it, we might have a better understanding of which parts of the protocol to fix and how to fix them in order to protect human rights 🌸

Overall, the revelations did, to some extent, contribute to the evolution of our ideas and perspectives ✨ Our next step should be to undertake research on the impact of Internet systems (including Internet protocols) on human rights, promote the implementation of protocols good for human rights through policy and advocacy, and focus on which technical parts we can standardize to help with more widespread implementation of human-rights-enabling Internet protocols 👑

---

5. Steven M. Bellovin: Governments and Cryptography: The Crypto Wars 🔐✨

5.1. Historical Background ✨

Okay so it's not a secret 🤫 Lots of governments really don't love it when people encrypt their traffic 🙄 They're totally fine with strong cryptography for themselves, but for everyone else? Absolutely not, whether "everyone else" means private citizens or other countries 💅 The history is way longer and messier than that, bestie 🎀

For a super long time, both governments and regular people used cryptography to protect their messages 🔐 The famous example is Julius Caesar, who is said to have encrypted messages by shifting letters in the alphabet by 3 [Kahn1996] 🏛️ In modern parlance, 3 was the key, and each letter got encrypted with

C[i] = (P[i] + 3) mod 23

(The Latin alphabet of his time had only 23 letters 🤓)

Known Arabic writings on cryptanalysis go back to at least the 8th century 📜 Their sophistication shows that encryption was reasonably commonly used 🧠 Then in the 9th century, Abū Yūsuf Yaʻqūb ibn ʼIsḥāq aṣ-Ṣabbāḥ al-Kindī developed and wrote about frequency analysis as a way to crack ciphers [Borda2011] [Kahn1996] 👑 Main character energy, honestly.

In an era of minimal literacy, though, there wasn't that much encryption, simply because most people could neither read nor write 📚🚫 Governments used encryption for diplomatic messages, and cryptanalysts followed close behind 🕵️‍♀️ The famed Black Chambers of the Renaissance era read messages from many different governments, while early cryptographers devised stronger and stronger ciphers [Kahn1996] 🌸 In Elizabethan England, Sir Francis Walsingham's intelligence agency intercepted and decrypted messages from Mary, Queen of Scots 😭 These messages formed some of the strongest evidence against her and eventually led to her execution [Kahn1996] 💀

This pattern continued for centuries 🕰️ In the United States, Thomas Jefferson invented the so-called wheel cipher in the late 18th century 🛞 It was reinvented about 100 years later by Étienne Bazeries and used as a standard American military cipher well into World War II [Kahn1996] Jefferson and other statesmen of the late 18th and early 19th centuries regularly used cryptography when communicating with each other 💌 An encrypted message was even part of the evidence introduced in Aaron Burr's 1807 trial for treason [Kerr2020] [Kahn1996] And Edgar Allan Poe claimed that he could cryptanalyze any message sent to him [Kahn1996] 🖤 Big confidence, Edgar.

The telegraph era upped the ante ⚡ In the US, just a year after Samuel Morse deployed his first telegraph line between Baltimore and Washington, his business partner, Francis Smith, published a codebook to help customers protect their traffic from prying eyes [Smith1845] In 1870, Britain nationalized its domestic telegraph network, and in response, Robert Slater published a more sophisticated codebook [Slater1870] 📠 On the government side, Britain took advantage of its position as the central node in the world's international telegraphic networks to read a great deal of traffic passing through the country [Headrick1991] [Kennedy1971] 👀 They used this ability strategically too 🎯 When war broke out in 1914, the British Navy cut Germany's undersea telegraph cables, forcing them to use radio 📡 An intercept of the so-called Zimmermann telegram, when cryptanalyzed, arguably led to American entry into the war and thence to Germany's defeat 🔥 Once the US entered the war, it required users of international telegraph lines to deposit copies of the codebooks they used for compression, so that censors could check messages for prohibited content [Kahn1996] 🙃

In Victorian Britain, private citizens, often lovers, used encryption in newspapers' personal columns to communicate without their parents' knowledge 💕 Charles Wheatstone and Charles Babbage used to solve these elementary ciphers routinely for their own amusement [Kahn1996] Nerds being nerds, iykyk 🤓

This pattern continued for many years 📆 Governments regularly used ciphers and codes, while other countries tried to break them 🥊 Private individuals would sometimes use encryption, but not often, and rarely well 🫠 But the two World Wars marked a sea change, one that would soon reverberate into the civilian world 🌊

The first World War featured vast troop movements by all parties 🪖 This in turn required a lot of encrypted communications, often by telegraph or radio 📻 These messages were often easily intercepted in bulk 😬 Furthermore, the difficulty of encrypting large volumes of plaintext led to the development of a variety of mechanical encryption devices, including Germany's famed Enigma machine ⚙️ World War II amplified both trends 📈 It also gave rise to machine-assisted cryptanalysis, such as the United Kingdom's bombes (derived from an earlier Polish design) and Colossus machine, and the American's device for cracking Japan's PURPLE system 🤖 The US also used punch card-based tabulators to assist in breaking other Japanese codes, such as the Japanese Imperial Navy's JN-25 [Kahn1996] [Rowlett1998] 🃏 Punch cards, the OG hardware, periodt 💅

These developments set the stage for the postwar SIGINT (Signals Intelligence) environment 🛰️ Many intragovernmental messages were sent by radio, making them easy to intercept, and advanced cryptanalytic machines made cryptanalysis easier 🧩 Ciphers were getting stronger, though, and government SIGINT agencies did not want to give up their access to data 🙅‍♀️ While there were undoubtedly many developments, two are well known 👇

The first involved CryptoAG, a Swedish (and later Swiss) manufacturer of encryption devices 🇸🇪🇨🇭 The head of that company, Boris Hagelin, was a friend of William F. Friedman, a pioneering American cryptologist. During the 1950s, CryptoAG sold its devices to other governments. Apparently at Friedman's behest, Hagelin weakened the encryption in a way that let the NSA read the traffic [Miller2020] 😱 Not the friend move, honestly.

The story involving the British is less well-documented and less clear 🌫️ When some of Britain's former colonies gained their independence, the British government gave them captured, war-surplus Enigma machines to protect their own traffic 🎁 Some authors contend that this was deceptive, in that these former colonies did not realize that the British could read Enigma-protected traffic. Others claim that this was obvious but that these countries didn't care: Britain was no longer their enemy, and it was neighboring countries they were worried about 🤷‍♀️ Again, though, this concerned governmental use of encryption [Kahn1996] [Baldwin2022] There was still little private use 🦋

---

5.2. The Crypto Wars Begin 💥

The modern era of conflict between an individual's desire for privacy and the government's desire to read traffic began around 1972 🎬 The grain harvest in the USSR had failed 🌾 Since relations between the Soviet Union and the United States were temporarily comparatively warm, the Soviet grain company (an arm of the Soviet government, of course 🙄) entered into negotiations with private American companies 🤝 Unknown to Americans at the time, Soviet intelligence was intercepting the phone calls of the American negotiating teams 📞😳 In other words, private companies had to deal with state actors as a threat 🚨 Eventually, US intelligence learned of this and came to a realization: the private sector needed strong cryptography too, to protect American national interests [Broad1982] [Johnson1998] This underscored the need for strong cryptography to protect American civilian traffic, but the SIGINT people were unhappy at the thought of more encryption that they couldn't break 😤

Meanwhile, the US was concerned about protecting unclassified data [Landau2014] 🗂️ In 1973 and again in 1974, the National Bureau of Standards (NBS) put out a call for a strong, modern encryption algorithm 📣 IBM submitted Lucifer, an internally developed algorithm based on what has become known as a 16-round Feistel network 🧬 The original version used a long key. It seemed quite strong, so NBS sent it off to the NSA to get their take 👀 The eventual design, adopted in 1976 as the Data Encryption Standard (DES), differed from Lucifer in some important ways 🔄 First, the so-called S-boxes, the source of the cryptologic strength of DES, were changed, and were now demonstrably not composed of random integers 🫢 Many researchers alleged that the S-boxes contained an NSA back door 🚪 It took nearly 20 years for the truth to come out: the S-boxes were in fact strengthened, not weakened 💪 Most likely, IBM independently discovered the attack now known as differential cryptanalysis, though some scholars suspect that the NSA told them about it 🤔 The nonrandom S-boxes protected against this attack ✅ The second change, though, was clearly insisted on by the NSA: the key size was shortened, from Lucifer's 112 bits to DES's 56 bits 📉 We now know that the NSA wanted a 48-bit key size, while IBM wanted 64 bits, and they compromised at 56 bits 🤝 Not the vibe, but the drama is iconic.

Whitfield Diffie and Martin Hellman, at Stanford University, wondered about the 56-bit keys 🧐 In 1979, they published a paper demonstrating that the US government, but few others, could afford to build a brute-force cracking machine, one that could try all 2^56 possible keys to crack a message 🖥️💸 NSA denied tampering with the design. A Senate investigating committee found that assertion to be correct, but did not discuss the shortened key length issue 🙃 Sus.

This, however, was not Diffie and Hellman's greatest contribution to cryptology 🏆 A few years earlier, they had published a paper inventing what is now known as public key cryptography 🗝️✨ (In fact, public key encryption had been invented a few years earlier at UK Government Communications Headquarters (GCHQ), but they kept their discovery classified until 1997 🤐) In 1978, Ronald Rivest, Adi Shamir, and Leonard Adleman devised the RSA algorithm, which made it usable 🎉 (An NSA employee, acting on his own, sent a letter warning that academic conferences on cryptology might violate US export laws 📮 The audacity.)

Around the same time, George Davida at the University of Wisconsin applied for a patent on a stream cipher, and the NSA slapped a secrecy order on the application 🚫 This barred him from even talking about his invention 🤐 The publicity was devastating, and the NSA had to back down 📰💥

The Crypto Wars had thus begun 🌪️ Civilians were inventing strong encryption systems, and the NSA was tampering with them or trying to suppress them 🥊 Bobby Inman, the then-director of the NSA, tried creating a voluntary review process for academic papers, but very few researchers were interested in participating [Landau1988] 🙅‍♀️ Nobody wanted to join that group chat 😂

There were few major public battles during the 1980s because there were few new major use cases for civilian cryptography during that time 😴 There was one notable incident, though 👀 Shamir, Amos Fiat, and Uriel Feige invented zero-knowledge proofs and applied for a US patent 🧠 In response, the US Army slapped a secrecy order on the patent 🪖 After a great deal of public outrage and intervention by, of all organizations, the NSA, the order was lifted on very narrow grounds: the inventors were not American, and they had been discussing their work all over the world [Landau1988] 🌍 The plot twist nobody asked for.

In the 1990s, though, everything changed. 🌈✨

5.3. The Battle Is Joined

okay so there were three major cryptography moments in the early 1990s 💅. First, Phil Zimmermann dropped PGP (Pretty Good Privacy) 🔐, a package for encrypting email messages. In 1993, AT&T planned to release the TSD-3600, an easy-to-use phone encryptor aimed at business travelers 📞. Shortly after that, Netscape Communications Corporation released SSL (Secure Socket Layer) so web-based commerce could work using their browser and web server 🛒. All of these were seen as threats by the NSA and the FBI 👀.

PGP was, at least arguably, covered by ITAR, the International Trafficking in Arms Regulations 🙃. Under American law, encryption software was treated like a weapon, so exporting it needed a license. It was also alleged to infringe the patents on the RSA algorithm. Honestly, both of those were a huge problem for something that was supposed to be open source 😭. Eventually the criminal investigation into Zimmermann's role in spreading PGP overseas was dropped, but the threat of those investigations stuck around to scare off everyone else [Levy2001].

The TSD-3600 was a whole different situation 🎀. AT&T was a major corporation that did not want to pick a fight with the US government, but international business travelers were a major market for the device. At the government's "request", the DES chip got swapped out for what became known as the Clipper chip. The Clipper chip used Skipjack, a cipher with 80-bit keys, so it was way stronger against brute-force attacks than DES. The catch? It came with "key escrow". Without going into any details, the key escrow mechanism let US government eavesdroppers consult a pair of (presumably secure) internal databases and decrypt all communications protected by the chip 🙈. Industry hated the Clipper chip, and it didn't help its reputation that AT&T Bell Labs' Matt Blaze found a weakness in the design [Blaze1994]. That weakness let you use Skipjack without the key escrow feature, which was honestly iconic of them to find 🧚.

The third major development, SSL, was even trickier 🌀. SSL was aimed at e-commerce, and of course Netscape wanted to sell its products outside the US. That would need an export license, so they made a deal with the government: non-American users would get a version that used 40-bit keys. That is a key length far shorter than what the NSA had agreed to 20 years earlier 💀. (To get ahead of the story: there was a compromise mode of operation, where an export-grade browser could use strong encryption when talking to a financial institution. This hybrid mode led to cryptographic weaknesses that were discovered some 20 years later [Adrian2015].)

Technologists and American industry pushed back 💪. The IETF adopted the Danvers Doctrine, described in [RFC3365]:

At the 32cd [sic] IETF held in Danvers, Massachusetts during April of 1995 the IESG asked the plenary for a consensus on the strength of security that should be provided by IETF standards. Although the immediate issue before the IETF was whether or not to support "export" grade security (which is to say weak security) in standards the question raised the generic issue of security in general. The overwhelming consensus was that the IETF should standardize on the use of the best security available, regardless of national policies. This consensus is often referred to as the "Danvers Doctrine".

Then American companies started losing business to overseas competitors, who didn't have to follow US export laws 📉. All of this led to what looked like a happy ending: the US government drastically loosened its export rules for cryptographic software 🎉. All was well, or so it seemed... 🌸

5.4. The Hidden Battle

Strong cryptography was here to stay, and it was no longer an American monopoly, if it ever really was 🌍. The Information Assurance Directorate of the NSA, the part of the agency that is supposed to protect US data, was pleased by the spread of strong cryptography 😌. When the Advanced Encryption Standard (AES) competition happened, there were no allegations of malign NSA interference. In fact, the winning entry was devised by two Europeans, Joan Daemen and Vincent Rijmen 🇪🇺. But the NSA and its SIGINT needs did not go away. The agency just adopted other techniques 🕵️‍♀️.

I have often noted that one doesn't go through strong security, one goes around it 🙄. When strong encryption became more common and much more necessary, the NSA started going around it, by targeting computers and the software that they run. And it seems clear that they believe AES is quite strong. They've even endorsed its use for protecting TOP SECRET information 💅. But there was an asterisk attached to that endorsement: AES is suitable if and only if properly used and implemented. Therein lies the rub 🥀.

The first apparent attempt to tamper with outside cryptographic mechanisms was discovered in 2007, when two Microsoft researchers, Dan Shumow and Niels Ferguson, noticed an odd property of a NIST-standardized random number generator, DUAL_EC_DRBG 🧐. (The NBS had been renamed to NIST, the National Institute of Standards and Technology.) Random numbers are vital for cryptography, and Shumow and Ferguson showed that if certain constants in DUAL_EC_DRBG were chosen in a particular way with a known-but-hidden other number, whoever knew that number could predict all future random numbers from a system, given a few sample bytes to start from [Kostyuk2022]. Those sample bytes could come from known keys, nonces, or anything else 😳. So where did the constants in DUAL_EC_DRBG come from, and how were they chosen or generated? No one who knows is talking 🤐. Cryptographers and security specialists were very suspicious, though. Bruce Schneier wrote in 2007, before more facts came out, that "both NIST and the NSA have some explaining to do", and I assigned my students reading on the topic 📚. Still, the issue didn't really get any traction until six years later. That's when, among the papers that Edward Snowden disclosed, was the information that the NSA had indeed tampered with a major cryptographic standard. Published reports did not specifically name DUAL_EC_DRBG or explain what the purpose was 🫠.

The revelations didn't stop there 😩. There have been allegations that the NSA paid some companies to use DUAL_EC_DRBG in their products. Some people have claimed that there were attempts to modify some IETF standards to make enough random bytes visible, to aid in exploiting the random number generator. A major vendor of networking gear, Juniper, did use DUAL_EC_DRBG in some of its products, but with different constants [Checkoway2016]. Where did those come from? Were they from the NSA or some other government? Could their source tree have been hacked by an intelligence agency? There was a different hack of their code at around the same time [Moore2015]. No one is talking 🤫.

The Snowden revelations also included data suggesting that the NSA had a worldwide eavesdropping network, and a group that tried very specific, targeted hacks on very specific targets' systems 👁️. In retrospect, neither is surprising: "spies gonna spy" 🕶️. The NSA's business is signals intelligence, so of course they're going to try to intercept traffic. Honestly, the DUAL_EC_DRBG tampering is useless to anyone who has not collected messages to decrypt 🗑️. And targeted hacks are a natural way around strong encryption: collect the data before it is encrypted or after it is decrypted, and don't worry about the strength of the algorithms 🎯.

The privacy community, worldwide, was appalled, though perhaps they shouldn't have been 😤. It calls to mind the line that Claude Rains' character uttered in the movie Casablanca [Curtiz]: "I'm shocked, shocked to find that gambling is going on in here." 🎰 The immediate and continuing reaction was to deploy more encryption ✨. The standards had long existed; what was missing was adoption. One barrier was the difficulty and expense of getting certificates to use with TLS, the successor to SSL. That void was filled by Let's Encrypt [LE], which made free certificates easy to get online 🆓. Today, most HTTP traffic is encrypted, so much so that Google's search engine down-ranks sites that do not use it 🔍. Major email providers uniformly use TLS to protect all traffic 📧. Wi-Fi, though a local area issue, now uses much stronger encryption 📶. (It's important to remember that security and insecurity have economic components. Security doesn't have to be perfect to be very useful, if it raises the attackers' costs by enough 💜.)

The news on the software side is less good 🥲. Not a day goes by when one does not read of organizations being hit by ransomware. It goes without saying that any threat actor capable of encrypting disks is also capable of stealing the information on them. In fact, that is a frequent accompanying activity, since the threat of disclosure is another incentive to pay for those sites that do have good enough backups 💸. Major vendors have put a lot of effort into securing their software, but bugs and operational errors by end-user sites persist 🫶.

5.5. Whither the IETF? 🌍✨

okay so signal intelligence agencies aren't going anywhere, bestie 😭. It's not just the NSA. Basically every major country has its own, and they all run into the same problems the NSA does, so they probably land on the same fixes 🕵️‍♀️. The real question is what we do to protect individual privacy 🫶. Some strong democracies, like Australia and the United Kingdom, are restarting the Crypto Wars and moving to restrict encryption 💀. The FBI and other law enforcement agencies keep complaining about it, so the US Congress keeps floating bills to do the same thing 🙄.

The IETF has always been committed to strong, ubiquitous encryption, and honestly that's iconic 💜. It needs to keep going, with cryptography and other security features built into protocols from day one 🎀. But maintenance matters too! Parameters like key lengths and modulus sizes age like milk 🥛. A value that's fine today might not be fine 10 years from now. (We've already seen apparent problems from 1024-bit moduli specified in an RFC. That RFC never got updated, even after technology caught up enough that attacking encryption based on them became feasible [Adrian2015]. 😬) The IETF can't control the code vendors ship or the code sites run, but it can tell the world when it thinks things have changed 📣.

Cryptoagility is becoming super important ⭐. In the next very few years we'll have so-called post-quantum algorithms, and both protocols and key lengths will need to change, maybe drastically 🌸. So is the IETF ready? 👀 What happens to something like DNSSEC if key lengths get drastically longer? Backwards compatibility will still matter, but of course that opens the door to other attacks 🚪. We've thought about those for a long time, but we need to make sure our mechanisms actually work, because we've been surprised before [BellovinRescorla2006] 🙈.

We also need to worry more about metadata 🧚. General Michael Hayden, former director of both the NSA and the CIA, once said, "We kill people based on metadata" [Ferran2014]. Wild, right? 💀 But caution is needed, because attempts to hide metadata can have side effects 🦋. A trivial example: Tor is really strong, but if your exit node is in a different country from you, websites that use IP geolocation might show you content in a language you don't read 🌐. Some sites even block connections from known Tor exit nodes 😤. More generally, lots of metadata-hiding schemes mean trusting a different party, and that party might turn out to be untrustworthy or become a target itself 👀. As another prominent IETFer put it, "Insecurity is like entropy; you can't destroy it, but you can move it around." 🌀 The IETF has done a lot, but it needs to do more 💖. And don't forget the risk isn't just governments acting directly. Private companies collect this data and sell it to all comers, and that's a whole mess too 💅.

Finally, the IETF must remember that its middle name is "Engineering" 🛠️✨. To me, a big part of engineering is picking the right solution in an over-constrained environment. Intelligence agencies won't go away, and neither will national restrictions on cryptography. So we have to pick the right path while staying true to our principles 👑🫶.

---

6. Security Considerations 🔐

Each or any of the authors may have forgotten or omitted things, or gotten things wrong. 🙏 We're sorry if that happened, but that's just the nature of a look-back like this 🥺. Still, such flaws almost certainly won't worsen security or privacy. Phew, but please still take this seriously. 🫶

7. IANA Considerations 📋

This document has no IANA actions. Nothing to register or change over at IANA here, bestie 💅.

8. Informative References 📚✨

[ACME] IETF, "Automated Certificate Management Environment (acme)", https://datatracker.ietf.org/wg/acme/about/.

[Adrian2015] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J. A., Heninger, N., Springhall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., and P. Zimmermann, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", CCS '15: Proceedings of the 22th ACM Conference on Computer and Communications Security, October 2015, https://dl.acm.org/doi/10.1145/2810103.2813707.

[Badii2021] Badiei, F., Fidler, B., and The Pennsylvania State University Press, "The Would-Be Technocracy: Evaluating Efforts to Direct and Control Social Change with Internet Protocol Design", Journal of Information Policy, vol. 11, pp. 376-402, DOI 10.5325/jinfopoli.11.2021.0376, December 2021, https://doi.org/10.5325/jinfopoli.11.2021.0376.

[Badii2023] Badiei, F., "Sanctions and the Internet", Digital Medusa, 2023, https://digitalmedusa.org/wp-content/uploads/2023/05/SanctionsandtheInternet-DigitalMedusa.pdf.

[Baldwin2022] Baldwin, M., "Did Britain sell Enigmas postwar?", Dr. Enigma, March 2022, https://drenigma.org/2022/03/02/did-britain-sell-enigmas-postwar/.

[BellovinRescorla2006] Bellovin, S. M. and E. K. Rescorla, "Deploying a New Hash Algorithm", Proceedings of NDSS '06, February 2006, https://www.cs.columbia.edu/~smb/papers/new-hash.pdf.

[Blaze1994] Blaze, M., "Protocol Failure in the Escrowed Encryption Standard", CCS '94: Proceedings of Second ACM Conference on Computer and Communications Security, 1994, https://dl.acm.org/doi/10.1145/191177.191193.

[Borda2011] Borda, M., "Fundamentals in Information Theory and Coding", Springer-Berlin, May 2011.

[Broad1982] Broad, W. J., "Evading the Soviet Ear at Glen Cove", Science, 217:4563, pp. 910-911, September 1982, https://www.science.org/doi/abs/10.1126/science.217.4563.910.

[CFRG] IRTF, "Crypto Forum (cfrg)", https://datatracker.ietf.org/rg/cfrg/about/.

[Checkoway2016] Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, R. P., Rescorla, E., and Hovav Shacham, "A Systematic Analysis of the Juniper Dual EC Incident", CCS '16: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pp. 468-479, October 2016, https://dl.acm.org/citation.cfm?id=2978395.

[CURDLE] IETF, "CURves, Deprecating and a Little more Encryption (curdle)", https://datatracker.ietf.org/wg/curdle/about/.

[Curtiz] Curtiz, M., Epstein, J. J., Epstein, P. G., and H. Koch, "Casablanca", Warner Bros. Pictures, November 1942.

[Doria2012] Liddicoat, J. and A. Doria, "Human Rights and Internet Protocols: Comparing Processes and Principles", The Internet Society, December 2012, https://www.internetsociety.org/resources/doc/2012/human-rights-and-internet-protocols-comparing-processes-and-principles/.

[Dual-EC] Bernstein, D., Lange, T., and R. Niederhagen, "Dual EC: A Standardized Back Door", July 2016, https://eprint.iacr.org/2015/767.pdf.

[Ferran2014] Ferran, L., "Ex-NSA Chief: "We Kill People Based on Metadata"", ABC News, May 2014, https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-we-kill-people-based-on-metadata.

[Garfinkel1995] Garfinkel, S., "PGP: Pretty Good Privacy", O'Reilly and Associates, January 1995.

[Guard2013] Greenwald, G., "NSA collecting phone records of millions of Verizon customers daily", The Guardian, June 2013.

[Headrick1991] Headrick, D. R., "The Invisible Weapon: Telecommunications and International Politics, 1851-1945", Oxford University Press, 1991.

[Johnson1998] Johnson, T. R., "American Cryptology During the Cold War, 1945-1989; Book III: Retrenchment and Reform, 1972-1980", Center for Cryptologic History, NSA, 1998, https://www.nsa.gov/portals/75/documents/news-features/declassified-documents/cryptologic-histories/cold_war_iii.pdf.

[Kahn1996] Kahn, D., "The Codebreakers: The Comprehensive History of Secret Communication from Ancient Times to the Internet", 2nd Edition, Scribner, 1996.

[Kennedy1971] Kennedy, P. M., "Imperial cable communications and strategy, 1870-1914", English Historical Review, 86:341, pp. 728-752, Oxford University Press, October 1971, https://www.jstor.org/stable/563928.

[Kerr2020] Kerr, O. S., "Decryption Originalism: The Lessons of Burr", Harvard Law Review, 134:905, January 2021, https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3533069.

[Kostyuk2022] Kostyuk, N. and S. Landau, "Dueling over DUAL_EC_DRBG: The Consequences of Corrupting a Cryptographic Standardization Process", Harvard National Security Journal, 13:2, pp. 224-284, June 2022, https://www.harvardnsj.org/wp-content/uploads/sites/13/2022/06/Vol13Iss2_Kostyuk-Landau_Dual-EC-DRGB.pdf.

[Landau1988] Landau, S., "Zero Knowledge and the Department of Defense", Notices of the American Mathematical Society, 35:1, pp. 5-12, January 1988, https://privacyink.org/pdf/Zero_Knowledge.pdf.

[Landau2014] Landau, S., "Under the Radar: NSA's Efforts to Secure Private-Sector Telecommunications Infrastructure", Journal of National Security Law & Policy, 7:3, September 2014, https://jnslp.com/wp-content/uploads/2015/03/NSA%E2%80%99s-Efforts-to-Secure-Private-Sector-Telecommunications-Infrastructure_2.pdf.

[LE] Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley, P., Flores-López, A., Halderman, A., Hoffman-Andrews, J., Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren, "Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web", CCS '19: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, November 2019, https://dl.acm.org/doi/pdf/10.1145/3319535.3363192.

[Levy2001] Levy, S., "Crypto: How the Code Rebels Beat the Government-Saving Privacy in the Digital Age", Penguin Publishing Group, January 2001.

[MADINAS] IETF, "MAC Address Device Identification for Network and Application Services (madinas)", https://datatracker.ietf.org/wg/madinas/about.

[Masnick2023] Masnick, M., "The Unintended Consequences of Internet Regulation", Copia, April 2023, https://copia.is/library/unintended-consequences/.

[Miller2020] Miller, G., "The intelligence coup of the century", The Washington Post, February 2020, https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/.

   [Moore2015]
              Moore, H. D., "CVE-2015-7755: Juniper ScreenOS
              Authentication Backdoor", Rapid7, December 2015,
              <https://www.rapid7.com/blog/post/2015/12/20/cve-
              2015-7755-juniper-screenos-authentication-backdoor/>.

   [MPLS-OPPORTUNISTIC-ENCRYPT]
              Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
              Networks", Work in Progress, Internet-Draft, draft-ietf-
              mpls-opportunistic-encrypt-03, 28 March 2017,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              opportunistic-encrypt-03>.

   [Perpass]  IETF, "perpass mailing list",
              <https://mailarchive.ietf.org/arch/browse/perpass/>.

   [Perpass-BoF]
              IETF, "perpass BoF -- Handling Pervasive Monitoring in the
              IETF", IETF 88 Proceedings, November 2013,
              <https://www.ietf.org/proceedings/88/perpass.html>.

   [Plenary-video]
              "IETF 88 Technical Plenary: Hardening The Internet",
              YouTube video, 2:37:28, posted by "IETF - Internet
              Engineering Task Force", November 2013,
              <https://www.youtube.com/
              watch?v=oV71hhEpQ20&pp=ygUQaWV0ZiA4OCBwbGVuYXJ5IA%3D%3D>.

   [Refs-to-7258]
              IETF, "References to RFC7258",
              <https://datatracker.ietf.org/doc/rfc7258/referencedby/>.

   [RFC1984]  IAB and IESG, "IAB and IESG Statement on Cryptographic
              Technology and the Internet", BCP 200, RFC 1984,
              DOI 10.17487/RFC1984, August 1996,
              <https://www.rfc-editor.org/info/rfc1984>.

   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, DOI 10.17487/RFC3365, August 2002,
              <https://www.rfc-editor.org/info/rfc3365>.

   [RFC6462]  Cooper, A., "Report from the Internet Privacy Workshop",
              RFC 6462, DOI 10.17487/RFC6462, January 2012,
              <https://www.rfc-editor.org/info/rfc6462>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7480, DOI 10.17487/RFC7480, March 2015,
              <https://www.rfc-editor.org/info/rfc7480>.

   [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 7481, DOI 10.17487/RFC7481, March 2015,
              <https://www.rfc-editor.org/info/rfc7481>.

   [RFC7687]  Farrell, S., Wenning, R., Bos, B., Blanchet, M., and H.
              Tschofenig, "Report from the Strengthening the Internet
              (STRINT) Workshop", RFC 7687, DOI 10.17487/RFC7687,
              December 2015, <https://www.rfc-editor.org/info/rfc7687>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8056]  Gould, J., "Extensible Provisioning Protocol (EPP) and
              Registration Data Access Protocol (RDAP) Status Mapping",
              RFC 8056, DOI 10.17487/RFC8056, January 2017,
              <https://www.rfc-editor.org/info/rfc8056>.

   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
              "Recommendation on Stable IPv6 Interface Identifiers",
              RFC 8064, DOI 10.17487/RFC8064, February 2017,
              <https://www.rfc-editor.org/info/rfc8064>.

   [RFC8280]  ten Oever, N. and C. Cath, "Research into Human Rights
              Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
              October 2017, <https://www.rfc-editor.org/info/rfc8280>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8461]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
              and J. Jones, "SMTP MTA Strict Transport Security (MTA-
              STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
              <https://www.rfc-editor.org/info/rfc8461>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
              "Temporary Address Extensions for Stateless Address
              Autoconfiguration in IPv6", RFC 8981,
              DOI 10.17487/RFC8981, February 2021,
              <https://www.rfc-editor.org/info/rfc8981>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
              Protocol (RDAP) Query Format", STD 95, RFC 9082,
              DOI 10.17487/RFC9082, June 2021,
              <https://www.rfc-editor.org/info/rfc9082>.

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/info/rfc9113>.

   [RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
              Access Protocol (RDAP) Service", STD 95, RFC 9224,
              DOI 10.17487/RFC9224, March 2022,
              <https://www.rfc-editor.org/info/rfc9224>.

   [Roth2022] Roth, E., "Internet backbone provider shuts off service in
              Russia", The Verge, March 2022,
              <https://www.theverge.com/2022/3/5/22962822/internet-
              backbone-provider-cogent-shuts-off-service-russia>.

   [Rowlett1998]
              Rowlett, F. B., "The Story of Magic, Memoirs of an
              American Cryptologic Pioneer", Aegean Park Press, 1998.

   [Slater1870]
              Slater, R., "Telegraphic Code, to Ensure Secresy in the
              Transmission of Telegrams", First Edition, W.R. Gray,
              1870, <https://books.google.com/books?id=MJYBAAAAQAAJ>.

   [Smith1845]
              Smith, F. O., "The Secret Corresponding Vocabulary:
              Adapted for Use to Morse's Electro-Magnetic Telegraph, and
              Also in Conducting Written Correspondence, Transmitted by
              the Mails, or Otherwise", Thurston, Isley & Company, 1845,
              <https://books.google.com/books?id=Z45clCxsF7EC>.

   [STRINT]   W3C and IAB, "A W3C/IAB workshop on Strengthening the
              Internet Against Pervasive Monitoring (STRINT)", March
              2014, <https://www.w3.org/2014/strint/>.

   [Timeline] Wikipedia, "Global surveillance disclosures
              (2013-present)", July 2023, <https://en.wikipedia.org/w/in
              dex.php?title=Global_surveillance_disclosures_(2013%E2%80%
              93present)&oldid=1161557819>.

   [TLS-ECH]  Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
              Encrypted Client Hello", Work in Progress, Internet-Draft,
              draft-ietf-tls-esni-16, 6 April 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              esni-16>.

   [Toronto]  Memmott, M., "Canada Used Airport Wi-Fi To Track
              Travelers, Snowden Leak Alleges", NPR, January 2014,
              <https://www.npr.org/sections/thetwo-
              way/2014/01/31/269418375/airport-wi-fi-used-to-track-
              travelers-snowden-leak-alleges>.

   [UTA]      IETF, "Using TLS in Applications (uta)",
              <https://datatracker.ietf.org/wg/uta/about>.

   [Zubhoff2019]
              Zuboff, S., "The Age of Surveillance Capitalism: The Fight
              for a Human Future at the New Frontier of Power",
              PublicAffairs, ISBN 9781781256855, January 2019.

That's the whole reference shelf, bestie, every single citation in its place 📚💅 Now let's shout out the people who made this happen 🫶

Acknowledgments 🫶

Susan Landau dropped a bunch of seriously valuable comments on Steve Bellovin's essay. Iconic behaviour 👑

We're sending big thank-yous to Carsten Bormann, Brian Carpenter, Wendy Grossman, Kathleen Moriarty, Jan Schaumann, Seth David Schoen, and Paul Wouters for reading and reviewing this text. Obviously, that does NOT mean they all agree with every word, lol 💀 Totally normal, totally fine ✨

This document was created at the behest of Eliot Lear, who also cat herded and did some editing. Honestly, cat herding a room full of protocol people is a whole main character moment 🐈🎀

Authors' Addresses 🎀

Here's where you can find the authors. Slide into those inboxes respectfully 💌

   Stephen Farrell
   Trinity College, Dublin
   Ireland
   Email: stephen.farrell@cs.tcd.ie


   Farzaneh Badii
   Digital Medusa
   Email: farzaneh.badii@gmail.com


   Bruce Schneier
   Harvard University
   United States of America
   Email: schneier@schneier.com


   Steven M. Bellovin
   Columbia University
   United States of America
   Email: smb@cs.columbia.edu