doc: Add RFC documents

1 files changed, 1682 insertions, 0 deletions

diff --git a/doc/rfc/rfc9446.txt b/doc/rfc/rfc9446.txt
new file mode 100644
index 0000000..ccf1394
--- /dev/null
+++ b/doc/rfc/rfc9446.txt
@@ -0,0 +1,1682 @@
+
+
+
+
+Independent Submission                                        S. Farrell
+Request for Comments: 9446                       Trinity College, Dublin
+Category: Informational                                         F. Badii
+ISSN: 2070-1721                                           Digital Medusa
+                                                             B. Schneier
+                                                      Harvard University
+                                                          S. M. Bellovin
+                                                     Columbia University
+                                                               July 2023
+
+
+         Reflections on Ten Years Past the Snowden Revelations
+
+Abstract
+
+   This memo contains the thoughts and recountings of events that
+   transpired during and after the release of information about the
+   United States National Security Agency (NSA) by Edward Snowden in
+   2013.  There are four perspectives: that of someone who was involved
+   with sifting through the information to responsibly inform the
+   public, that of a security area director of the IETF, that of a human
+   rights expert, and that of a computer science and affiliate law
+   professor.  The purpose of this memo is to provide some historical
+   perspective, while at the same time offering a view as to what
+   security and privacy challenges the technical community should
+   consider.  These essays do not represent a consensus view, but that
+   of the individual authors.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   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 of this document.  Please review these documents
+   carefully, as 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
+
+   On June 6th, 2013, an article appeared in _The Guardian_ [Guard2013]
+   that was the beginning of a series of what have come to be known as
+   the Snowden revelations, describing certain activities of the United
+   States National Security Agency (NSA).  These activities included,
+   amongst others: secret court orders; secret agreements for the
+   receipt of so-called "meta-information" that includes source,
+   destination, and timing of communications; and tapping of
+   communications lines.  The breathtaking scope of the operations
+   shocked the Internet technical community and resulted in a sea change
+   within the IETF, IAB, and other standards organizations.
+
+   Now that some years have passed, it seems appropriate to reflect on
+   that period of time and to consider what effect the community's
+   actions had, where security has improved, how the threat surface has
+   evolved, what areas haven't improved, and where the community might
+   invest future efforts.
+
+   Bruce Schneier begins this compendium of individual essays by
+   bringing us back to 2013, recalling how it was for him and others to
+   report what was happening, and the mindset of those involved.  Next,
+   Stephen Farrell reviews the technical community's reactions and in
+   particular the reactions of the IETF community, technical advances,
+   and where threats remain.  Then Farzaneh Badii discusses the impact
+   of those advances -- or lack thereof -- on human rights.  Finally
+   Steven M.  Bellovin puts the Snowden revelations into an ever-
+   evolving historical context of secrets and secret stealing that spans
+   centuries, closing with some suggestions for IETF.
+
+   Readers are invited to consider what impact we as a community have
+   had, what challenges remain, and what positive contribution the
+   technical community can and should make to address 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, I wrote extensively about new revelations regarding
+   NSA surveillance based on the documents provided by Edward Snowden.
+   But I had a more personal involvement as well.
+
+   I wrote the essay below in September 2013. _The New Yorker_ agreed to
+   publish it, but _The Guardian_ asked me not to.  It was scared of UK
+   law enforcement and worried that this essay would reflect badly on
+   it.  And given that the UK police would raid its offices in July
+   2014, it had legitimate cause to be worried.
+
+   Now, ten years later, I offer this as a time capsule of what those
+   early months of Snowden were like.
+
+   |  It's a surreal experience, paging through hundreds of top-secret
+   |  NSA documents.  You're peering into a forbidden world: strange,
+   |  confusing, and fascinating all at the same time.
+   |  
+   |  I had flown down to Rio de Janeiro in late August at the request
+   |  of Glenn Greenwald.  He had been working on the Edward Snowden
+   |  archive for a couple of months, and had a pile of more technical
+   |  documents that he wanted help interpreting.  According to
+   |  Greenwald, Snowden also thought that bringing me down was a good
+   |  idea.
+   |  
+   |  It made sense.  I didn't know either of them, but I have been
+   |  writing about cryptography, security, and privacy for decades.  I
+   |  could decipher some of the technical language that Greenwald had
+   |  difficulty with, and understand the context and importance of
+   |  various document.  And I have long been publicly critical of the
+   |  NSA's eavesdropping capabilities.  My knowledge and expertise
+   |  could help figure out which stories needed to be reported.
+   |  
+   |  I thought about it a lot before agreeing.  This was before David
+   |  Miranda, Greenwald's partner, was detained at Heathrow airport by
+   |  the UK authorities; but even without that, I knew there was a
+   |  risk.  I fly a lot -- a quarter of a million miles per year -- and
+   |  being put on a TSA list, or being detained at the US border and
+   |  having 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 some time on the phone with the attorneys recommended
+   |  to me by the ACLU and the EFF.  And I talked about it with my
+   |  partner, especially when Miranda was detained three days before my
+   |  departure.  Both Greenwald and his employer, _The Guardian_, are
+   |  careful about whom they show the documents to.  They publish only
+   |  those portions essential to getting the story out.  It was
+   |  important to them that I be a co-author, not a source.  I didn't
+   |  follow the legal reasoning, but the point is that _The Guardian_
+   |  doesn't want to leak the documents to random people.  It will,
+   |  however, write stories in the public interest, and I would be
+   |  allowed to review the documents as part of that process.  So after
+   |  a Skype conversation with someone at _The Guardian_, I signed a
+   |  letter of engagement.
+   |  
+   |  And then I flew to Brazil.
+   |  
+   |  I saw only a tiny slice of the documents, and most of what I saw
+   |  was surprisingly banal.  The concerns of the top-secret world are
+   |  largely tactical: system upgrades, operational problems owing to
+   |  weather, delays because of work backlogs, and so on.  I paged
+   |  through weekly reports, presentation slides from status meetings,
+   |  and general briefings to educate visitors.  Management is
+   |  management, even inside the NSA.  Reading the documents, I felt as
+   |  though I were sitting through some of those endless meetings.
+   |  
+   |  The meeting presenters try to spice things up.  Presentations
+   |  regularly include intelligence success stories.  There were
+   |  details -- what had been found, and how, and where it helped --
+   |  and sometimes there were attaboys from "customers" who used the
+   |  intelligence.  I'm sure these are intended to remind NSA employees
+   |  that they're doing good.  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 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 --
+   |  really, I am not making that one up -- is; how TURBINE works.
+   |  Those secrets collectively have a code name -- ECI, for
+   |  exceptionally compartmented information -- and almost never appear
+   |  in the documents.  Chatting with Snowden on an encrypted IM
+   |  connection, I joked that the NSA cafeteria menu probably has code
+   |  names for 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 some of that more than
+   |  ten-billion-dollar annual budget and hire yourself a design firm.
+   |  Really; it'll pay off in morale.
+   |  
+   |  Once in a while, though, I would see something that made me stop,
+   |  stand up, and pace around in circles.  It wasn't that what I read
+   |  was particularly exciting, or important.  It was just that it was
+   |  startling.  It changed -- ever so slightly -- how I thought about
+   |  the world.
+   |  
+   |  Greenwald said that 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
+   |  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 say 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.
+   |  
+   |  It turned out to be a terrible week to visit Greenwald, as he was
+   |  still dealing with the fallout from Miranda's detention.  Two
+   |  other journalists, one from _The Nation_ and the other from _The
+   |  Hindu_, were also in town working with him.  A lot of my week
+   |  involved Greenwald rushing into my hotel room, giving me a thumb
+   |  drive of new stuff to look through, and rushing 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 given the capability 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 algorithms I knew that the US government used.
+   |  
+   |  I tried to talk to Greenwald about his own operational security.
+   |  It had been incredibly stupid for Miranda to be traveling with NSA
+   |  documents on the thumb drive.  Transferring files electronically
+   |  is 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 hinder professionals.  I'm sure
+   |  that 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.  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 for it?  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 that the NSA was doing things like this.  But we
+   |  never really sat down and figured out the details, and to have the
+   |  details confirmed made a big difference.  Maybe I can make it
+   |  clearer with an analogy.  Everyone knows that death is inevitable;
+   |  there's absolutely no surprise about that.  Yet it 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 that
+   |  it is 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 the
+   |  details of how it is doing it.
+   |  
+   |  I also found it incredibly difficult 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
+   |  therapy; I would wake up in the wee hours of the morning, and
+   |  write an essay.  But that 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 will get worse again when I find
+   |  another monumental revelation; 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 is 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 release are carefully redacted.
+   |  Greenwald and I repeatedly debated with _The Guardian_ editors 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.  Despite that, 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 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 remain 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 so 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
+   |  throwing them into the wastebasket.  I was printing documents
+   |  marked "TOP SECRET/COMINT/NOFORN" in a hotel lobby.  And once, I
+   |  took the wrong thumb drive with me to dinner, accidentally leaving
+   |  the unencrypted one filled with top-secret documents in my hotel
+   |  room.  It was an honest mistake; they were both blue.
+   |  
+   |  If I were an NSA employee, the policy would be to fire me for that
+   |  alone.
+   |  
+   |  Many have written about how being under constant surveillance
+   |  changes a person.  When you know you're being watched, you censor
+   |  yourself.  You become less open, less spontaneous.  You look at
+   |  what you write on your computer and dwell on what you've said on
+   |  the telephone, wonder how it would sound taken out of context,
+   |  from the perspective of a hypothetical observer.  You're more
+   |  likely to conform.  You suppress your individuality.  Even though
+   |  I have worked in privacy for decades, and already knew a lot about
+   |  the NSA and what it does, the change was palpable.  That feeling
+   |  hasn't faded.  I am now more careful about what I say and write.
+   |  I am less trusting of communications technology.  I am less
+   |  trusting of the computer industry.
+   |  
+   |  After much discussion, Greenwald and I agreed to write three
+   |  stories together to start.  All of those are still in progress.
+   |  In addition, I wrote two commentaries on the Snowden documents
+   |  that were recently made public.  There's a lot more to come; even
+   |  Greenwald hasn't looked through everything.
+   |  
+   |  Since my trip to Brazil (one month before), I've flown back to the
+   |  US once and domestically seven times -- all without incident.  I'm
+   |  not on any list yet.  At least, none that I know about.
+
+   As it happened, I didn't write much more with Greenwald or _The
+   Guardian_. Those two had a falling out, and by the time everything
+   settled and both began writing about the documents independently --
+   Greenwald at the newly formed website _The Intercept_ -- I got cut
+   out of the process somehow.  I remember hearing that Greenwald was
+   annoyed with me, but I never learned the reason.  We haven't spoken
+   since.
+
+   Still, I was happy with the one story I was part of: how the NSA
+   hacks Tor. I consider it a personal success that I pushed _The
+   Guardian_ to publish NSA documents detailing QUANTUM.  I don't think
+   that would have gotten out any other way.  And I still use those
+   pages today when I teach cybersecurity to policymakers at the Harvard
+   Kennedy School.
+
+   Other people wrote about the Snowden files, and wrote a lot.  It was
+   a slow trickle at first, and then a more consistent flow.  Between
+   Greenwald, Bart Gellman, and _The Guardian_ reporters, there ended up
+   being steady stream of news.  (Bart brought in Ashkan Soltani to help
+   him with the technical aspects, which was a great move on his part,
+   even if it cost Ashkan a government job later.)  More stories were
+   covered by other publications.
+
+   It started getting weird.  Both Greenwald and Gellman held documents
+   back so they could publish them in their books.  Jake Appelbaum, who
+   had not 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, I am convinced that the document was not in the Snowden
+   archives: that Jake got it somehow, and it was released with the
+   implication that it was from Edward Snowden.  I thought it was
+   important enough that I started writing about each item in that
+   document in my blog: "NSA Exploit of the Week."  That got my website
+   blocked by the DoD: I keep a framed print of the censor's message on
+   my wall.
+
+   Perhaps the most surreal document 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 before.)
+
+   I ended up being something of a public ambassador for the documents.
+   When I got back from Rio, I gave talks at a private conference in
+   Woods Hole, the Berkman Center at Harvard, something called the
+   Congress on Privacy and Surveillance in Geneva, events at both CATO
+   and New America in DC, an event at the University of Pennsylvania, an
+   event at EPIC, a "Stop Watching Us" rally in DC, the RISCS conference
+   in London, the ISF in Paris, and...then...at the IETF meeting in
+   Vancouver in November 2013.  (I remember little of this; I am
+   reconstructing it all from my calendar.)
+
+   What struck me at the IETF was the indignation in the room, and the
+   calls to action.  And there was action, across many 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, investigations by Congress, pronouncements by President
+   Obama, and federal court rulings, I don't think much has changed.
+   The NSA canceled a program here and a program there, and it is now
+   more public about defense.  But I don't think it is any less
+   aggressive about either bulk or targeted surveillance.  Certainly its
+   government authorities haven't been restricted in any way.  And
+   surveillance capitalism is still the business model of the Internet.
+
+   And Edward Snowden?  We were in contact for a while on Signal.  I
+   visited him once in Moscow, in 2016.  And I had him do a guest
+   lecture to my class at Harvard for a few years, remotely by Jitsi.
+   Afterwards, I would hold a session where I promised to answer every
+   question he would evade or not answer, explain every response he did
+   give, and be candid in a way that someone with an outstanding arrest
+   warrant simply cannot.  Sometimes I thought I could channel Snowden
+   better than he could.
+
+   But now it's been a decade.  Everything he knows is old and out of
+   date.  Everything we know is old and out of date.  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.  It again
+   has capabilities we can only surmise.
+
+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].  While the potential for such was known, it was the scale
+   and pervasiveness of the activities disclosed that was alarming and,
+   I think it fair to say, quite annoying, for very many Internet
+   engineers.
+
+   As for the IETF's reaction, informal meetings during the July 2013
+   IETF meeting in Berlin indicated that IETF participants considered
+   that these revelations showed that we needed to do more to improve
+   the security and privacy properties of IETF protocols, and to help
+   ensure 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 venue for triaging
+   proposals for work on these topics.  At the November 2013 IETF
+   meeting, there was a lively and very well attended plenary session
+   [Plenary-video] on "hardening the Internet" against such attacks,
+   followed by a "birds of a feather" session [Perpass-BoF] devoted to
+   more detailed discussion of possible actions in terms of new working
+   groups, protocols, and Best Current Practice (BCP) documents that
+   could help improve matters.  This was followed in February/March 2014
+   by a joint IAB/W3C workshop on "strengthening the Internet against
+   pervasive monitoring" [STRINT] held in London and attended by 150
+   engineers (still the only IAB workshop in my experience where we
+   needed a waiting list for people after capacity for the venue was
+   reached!).  The STRINT workshop report was eventually published as
+   [RFC7687] in 2015, but in the meantime, work proceeded on a BCP
+   document codifying that the IETF community considered that "pervasive
+   monitoring is an attack" [RFC7258] (aka BCP 188).  The IETF Last Call
+   discussion for that short document included more than 1000 emails --
+   while there was broad agreement on the overall message, a number of
+   IETF participants considered enshrining that message in the RFC
+   Series and IETF processes controversial.  In any case, the BCP was
+   published in May 2014.  The key statement on which rough consensus
+   was reached 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 justifying additional work on security and privacy.  Throughout
+   that period and beyond, the repercussions of the Snowden revelations
+   remained a major and ongoing agenda item for both of the IETF's main
+   technical management bodies, the IAB and the IESG (on which I served
+   at the time).
+
+   So far, I've only described the processes with which the IETF dealt
+   with the attacks, but there was, of course, also much technical work
+   started by IETF participants that was at least partly motivated by
+   the Snowden revelations.
+
+   In November 2013, a working group was established to document better
+   practices for using TLS in applications [UTA] so that deployments
+   would be less at risk in the face of some of the attacks related to
+   stripping TLS or having applications misuse TLS APIs or parameters.
+   Similar work was done later to update recommendations for use of
+   cryptography in other protocols in the CURDLE Working Group [CURDLE].
+   The CURDLE Working Group was, to an extent, created to enable use of
+   a set of new elliptic curves that had been documented by the IRTF
+   Crypto Forum Research Group [CFRG].  That work in turn had been
+   partly motivated by (perhaps ultimately unfounded) concerns about
+   elliptic curves defined in NIST standards, following the DUAL_EC_DRBG
+   debacle [Dual-EC] (described further below) where a NIST random
+   number generator had been deliberately engineered to produce output
+   that could be vulnerable to NSA attack.
+
+   Work to develop a new version of TLS was started in 2014, mainly due
+   to concerns that TLS 1.2 and earlier version implementations had been
+   shown to be vulnerable to a range of attacks over the years.  The
+   work to develop TLS 1.3 [RFC8446] also aimed to encrypt more of the
+   handshake so as to expose less information to network observers -- a
+   fairly direct result of the Snowden revelations.  Work to further
+   improve TLS in this respect continues today using the so-called
+   Encrypted Client Hello (ECH) mechanism [TLS-ECH] to remove one of the
+   last privacy leaks present in current TLS.
+
+   Work on ECH was enabled by significant developments to encrypt DNS
+   traffic, using DNS over TLS (DoT) [RFC7858] or DNS Queries over HTTPS
+   (DoH) [RFC8484], which also started as a result of the Snowden
+   revelations.  Prior to that, privacy hadn't really been considered
+   when it came to DNS data or (more importantly) the act of accessing
+   DNS data.  The trend towards encrypting DNS traffic represents a
+   significant change for the Internet, both in terms of reducing
+   cleartext, but also in terms of moving points-of-control.  The latter
+   aspect was, and remains, controversial, but the IETF did its job of
+   defining new protocols that can enable better DNS privacy.  Work on
+   HTTP version 2 [RFC9113] and QUIC [RFC9000] further demonstrates the
+   trend in the IETF towards always encrypting protocols as the new
+   norm, at least at and above the transport layer.
+
+   Of course, not all such initiatives bore fruit; for example, attempts
+   to define a new MPLS encryption mechanism
+   [MPLS-OPPORTUNISTIC-ENCRYPT] foundered due to a lack of interest and
+   the existence of the already deployed IEEE Media Access Control
+   Security (MACsec) scheme.  But there has been a fairly clear trend
+   towards trying to remove cleartext from the Internet as a precursor
+   to provide improved privacy when considering network observers as
+   attackers.
+
+   The IETF, of course, forms only one part of the broader Internet
+   technical community, and there were many non-IETF activities
+   triggered by the Snowden revelations, a number of which also
+   eventually resulted in new IETF work to standardise better security
+   and privacy mechanisms developed elsewhere.
+
+   In 2013, the web was largely unencrypted despite HTTPS being
+   relatively usable, and that was partly due to problems using the Web
+   PKI at scale.  The Let's Encrypt initiative [LE] issued its first
+   certificates in 2015 as part of its aim to try to move the web
+   towards being fully encrypted, and it has been extremely successful
+   in helping achieve that goal.  Subsequently, the automation protocols
+   developed for Let's Encrypt were standardised in the IETF's ACME
+   Working Group [ACME].
+
+   In 2013, most email transport between mail servers was cleartext,
+   directly enabling some of the attacks documented in the Snowden
+   documents.  Significant effort by major mail services and MTA
+   software developers since then have resulted in more than 90% of
+   email being encrypted between mail servers, and various IETF
+   protocols have been defined in order to improve that situation, e.g.,
+   SMTP MTA Strict Transport Security (MTA-STS) [RFC8461].
+
+   Lastly, MAC addresses have historically been long-term fixed values
+   visible to local networks (and beyond), which enabled some tracking
+   attacks that were documented in the Snowden documents [Toronto].
+   Implementers, vendors, and the IEEE 802 standards group recognised
+   this weakness and started work on MAC address randomisation that in
+   turn led to the IETF's MADINAS Working Group [MADINAS], which aims to
+   ensure randomised MAC addresses can be used on the Internet without
+   causing unintentional harm.  There is also a history of IETF work on
+   deprecating MAC-address-based IPv6 interface identifiers and
+   advocating pseudorandom identifiers and temporary addresses, some of
+   which pre-dates Snowden [RFC7217] [RFC8064] [RFC8981].
+
+   In summary, the significantly large volume of technical work pursued
+   in the IETF and elsewhere as a result of the Snowden revelations has
+   focussed on two main things: decreasing the amount of plaintext that
+   remains visible to network observers and secondly reducing the number
+   of long-term identifiers that enable unexpected identification or re-
+   identification of devices or users.  This work is not by any means
+   complete, nor is deployment universal, but significant progress has
+   been made, and the work continues even if the level of annoyance at
+   the attack has faded somewhat over time.
+
+   One should also note that there has been pushback against these
+   improvements in security and privacy and the changes they cause for
+   deployments.  That has come from more or less two camps: those on
+   whom these improvements force change tend to react badly, but later
+   figure out how to adjust, and those who seemingly prefer not to
+   strengthen security so as to, for example, continue to achieve what
+   they call "visibility" even in the face of the many engineers who
+   correctly argue that such an anti-encryption approach inevitably
+   leads to worse security overall.  The recurring nature of this kind
+   of pushback is nicely illustrated by [RFC1984].  That informational
+   document was published in 1996 as an IETF response to an early
+   iteration of the perennial "encryption is bad" argument.  In 2015,
+   the unmodified 1996 text was upgraded to a BCP (BCP 200) as the
+   underlying arguments have not changed, and will not change.
+
+   Looking back on all the above from a 2023 vantage point, I think
+   that, as a community of Internet engineers, we got a lot right, but
+   that 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.  In part, that's because many of the
+   problems are outside of the scope of bodies such as the IETF.  For
+   example, intrusive backend sharing of people's data for advertising
+   purposes can't really be mitigated via Internet protocols.
+
+   However, I also think that the real annoyance felt with respect to
+   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 that bad actors are
+   limited to governments, and 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 be mitigated where possible.  However, the
+   Internet technical community clearly hasn't acted in that way over
+   the last decade.
+
+   Perhaps that indicates that Internet engineers and the bodies in
+   which they congregate need to place much more emphasis on standards
+   for ethical behaviour than has been the case for the first half-
+   century of the Internet.  And while it would be good to see the
+   current leaders of Internet bodies work to make progress in that
+   regard, at the time of writing, it sadly seems more likely that
+   government regulators will be the ones to try force better behaviour.
+   That of course comes with a significant risk of having regulations
+   that stymie the kind of permissionless innovation that characterised
+   many earlier Internet successes.
+
+   So while we got a lot right in our reaction to Snowden's revelations,
+   currently, we have a "worse" Internet.  Nonetheless, I do still hope
+   to see a sea change there, 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 have
+   been witnessing dominant regulatory and policy approaches that impact
+   technologies and services that are 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 the Internet governance and technical approaches to
+   support human rights such as freedom of expression, freedom of
+   association and assembly, and privacy.  It did not decrease the
+   number of Internet shutdowns nor the eagerness of authoritarian (and
+   even to some extent democratic) countries to territorialize the
+   Internet.  In some cases, the 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 IETF had lost sight of issues such as
+   privacy and surveillance.  There were instances of resistance to
+   surveillance in the past by engineers (we do not 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 Center for Democracy and
+   Technology (CDT) was undertaking work at the IETF (and was 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.  It might have also 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)."
+
+   During the past decade, a few successful strides were made to create
+   protocols that, when and if implemented, aim at protecting privacy of
+   the users, as well as help with reducing pervasive surveillance.
+   These efforts were in keeping with the consensus of the IETF found in
+   RFC 7258.  Sometimes these protocols have anti-censorship qualities
+   as well.  A few examples immediately come to mind: 1) the encryption
+   of DNS queries (for example, DNS over HTTPS), 2) ACME protocol
+   underpinning the Let's Encrypt initiative, and 3) Registration Data
+   Access Protocol (RDAP) [RFC7480] [RFC7481] [RFC8056] [RFC9082]
+   [RFC9083] [RFC9224].  (It is debatable that RDAP had anything to do
+   with the Snowden revelations, 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 due to being expensive or
+   unnecessary, but the Snowden revelations made it 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 but
+   at the same time enabling legitimate access to the information.  As
+   to the work of HRPC Research Group, it has so far issued [RFC8280] by
+   ten Oever and Cath and a number of informational Internet-Drafts.
+
+   While we cannot really argue that all the movements and 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 that the revelations
+   helped with expediting the resolution of some of the "technical"
+   hesitations that had an effect on fixing Internet protocols that
+   enabled 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.
+
+   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 (Cross
+   Registry Internet Service Protocol (CRISP) and later on 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 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 implementation of DoH include
+   protection of children online and lack of law enforcement access to
+   data.
+
+   We must acknowledge that sometimes the technical solutions that we
+   use that 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,
+   have an impact on which and whose human rights.
+
+   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 to 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
+
+   It's not a secret: many governments in the world don't like it when
+   people encrypt their traffic.  More precisely, they like strong
+   cryptography for themselves but not for others, whether those others
+   are private citizens or other countries.  But the history is longer
+   and more complex than that.
+
+   For much of written history, both governments and individuals used
+   cryptography to protect their messages.  To cite just one famous
+   example, Julius Caesar 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 was 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.
+   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].
+
+   In an era of minimal literacy, though, there wasn't that much use of
+   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 times in 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].  Edgar Allan Poe claimed that he could cryptanalyze any
+   message sent to him [Kahn1996].
+
+   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; 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].
+
+   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].
+
+   These developments set the stage for the postwar SIGINT (Signals
+   Intelligence) environment.  Many intragovernmental messages were sent
+   by radio, making them easy to intercept; 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].
+
+   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; 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 desires 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, which
+   was adopted in 1976 as the Data Encryption Standard (DES), differed
+   in some important ways from Lucifer.  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; they compromised at 56
+   bits.
+
+   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.
+
+   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.)
+
+   Around the same time, George Davida at the University of Wisconsin
+   applied for a patent on a stream cipher; the NSA slapped a secrecy
+   order on the application.  This barred him from even talking about
+   his invention.  The publicity was devastating; 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].
+
+   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].
+
+   In the 1990s, though, everything changed.
+
+5.3.  The Battle Is Joined
+
+   There were three major developments in cryptography in the early
+   1990s.  First, Phil Zimmermann released PGP (Pretty Good Privacy), a
+   package to encrypt 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, the Netscape Communications
+   Corporation released SSL (Secure Socket Layer) as a way to enable
+   web-based commerce 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 what was known as ITAR, the
+   International Trafficking in Arms Regulations -- under American law,
+   encryption software was regarded as a weapon, so exports required a
+   license.  It was also alleged to infringe the patents on the RSA
+   algorithm.  Needless to say, both issues were problematic for what
+   was intended to be open source software.  Eventually, the criminal
+   investigation into Zimmermann's role in the spread of PGP overseas
+   was dropped, but the threat of such investigations remained to deter
+   others [Levy2001].
+
+   The TSD-3600 was another matter.  AT&T was a major corporation that
+   did not want to pick a fight with the US government, but
+   international business travelers were seen as a major market for the
+   device.  At the government's "request", the DES chip was replaced
+   with what was known as the Clipper chip.  The Clipper chip used
+   Skipjack, a cipher with 80-bit keys; it was thus much stronger
+   against brute-force attacks than DES.  However, it provided "key
+   escrow".  Without going into any details, the key escrow mechanism
+   allowed US government eavesdroppers to consult a pair of (presumably
+   secure) internal databases and decrypt all communications protected
+   by the chip.  The Clipper chip proved to be extremely unpopular with
+   industry; that AT&T Bell Labs' Matt Blaze found a weakness in the
+   design [Blaze1994], one that let you use Skipjack without the key
+   escrow feature, didn't help its reputation.
+
+   The third major development, SSL, was even trickier.  SSL was aimed
+   at e-commerce, and of course Netscape wanted to be able to sell its
+   products outside the US.  That would require an export license, so
+   they made a deal with the government: non-American users would
+   receive a version that used 40-bit keys, 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, wherein an
+   export-grade browser could use strong encryption when talking to a
+   financial institution.  This hybrid mode led to cryptographic
+   weaknesses 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 their overseas
+   competitors, who did not have to comply with US export laws.  All of
+   this led to what seemed like a happy conclusion: 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 indeed it ever 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 was held,
+   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 merely 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 that 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, noted 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, but 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].  These
+   sample bytes could come from known keys, nonces, or anything else.
+   Where did the constants in DUAL_EC_DRBG come from and how were they
+   chosen or generated?  No one who knows is talking.  But although
+   cryptographers and security specialists were very suspicious -- Bruce
+   Schneier wrote in 2007, before more facts came out, that "both NIST
+   and the NSA have some explaining to do"; I assigned my students
+   reading on the topic -- the issue didn't really get any traction
+   until six years later, when among the papers that Edward Snowden
+   disclosed was the information that the NSA had indeed tampered with a
+   major cryptographic standard, though 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 these 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; of course they're going to try to
+   intercept traffic.  Indeed, 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
+   have 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; indeed, 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?
+
+   Signal intelligence agencies, not just the NSA, but its peers around
+   the globe -- most major countries have their own -- are not going to
+   go away.  The challenges that have beset the NSA are common to all
+   such agencies, and their solutions are likely the same.  The question
+   is what should be done to protect individual privacy.  A number of
+   strong democracies, such as Australia and the United Kingdom, are, in
+   a resumption of the Crypto Wars, moving to restrict encryption.
+   Spurred on by complaints from the FBI and other law enforcement
+   agencies, the US Congress frequently considers bills to do the same.
+
+   The IETF has long had a commitment to strong, ubiquitous encryption.
+   This is a good thing.  It needs to continue, with cryptography and
+   other security features designed into protocols from the beginning.
+   But there is also a need for maintenance.  Parameters such as key
+   lengths and modulus sizes age; a value that is acceptable today may
+   not be 10 years hence.  (We've already seen apparent problems from
+   1024-bit moduli specified in an RFC, an RFC that was not modified
+   when technology improved enough that attacking encryption based on
+   them had become feasible [Adrian2015].)  The IETF can do nothing
+   about the code that vendors ship or that sites use, but it can alert
+   the world that it thinks things have changed.
+
+   Cryptoagility is of increasing importance.  In the next very few
+   years, we will have so-called post-quantum algorithms.  Both
+   protocols and key lengths will need to change, perhaps drastically.
+   Is the IETF ready?  What will happen to, say, DNSSEC if key lengths
+   become drastically longer?  Backwards compatibility will remain
+   important, but that, of course, opens the door to other attacks.
+   We've long thought about them; we need to be sure that our mechanisms
+   work -- we've been surprised in the past [BellovinRescorla2006].
+
+   We also need to worry more about metadata.  General Michael Hayden,
+   former director of both the NSA and the CIA, once remarked, "We kill
+   people based on metadata" [Ferran2014].  But caution is necessary;
+   attempts to hide metadata can have side effects.  To give a trivial
+   example, Tor is quite strong, but if your exit node is in a different
+   country than you are in, web sites that use IP geolocation may
+   present their content in a language foreign to you.  Some sites even
+   block connections from known Tor exit nodes.  More generally, many
+   attempts to hide metadata involve trusting a different party; that
+   party may turn out to be untrustworthy or it may itself become a
+   target of attack.  As another prominent IETFer has remarked,
+   "Insecurity is like entropy; you can't destroy it, but you can move
+   it around."  The IETF has done a lot; it needs to do more.  And
+   remember that the risk here is not just governments acting directly,
+   it's also private companies that collect the data and sell it to all
+   comers.
+
+   Finally, the IETF must remember that its middle name is
+   "Engineering".  To me, one of the attributes of engineering is the
+   art of picking the right solution in an over-constrained environment.
+   Intelligence agencies won't go away, nor will national restrictions
+   on cryptography.  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's the case, but that's in
+   the nature of a look-back such as this.  Such flaws almost certainly
+   won't worsen security or privacy, though.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+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.
+
+Acknowledgments
+
+   Susan Landau added many valuable comments to Steve Bellovin's essay.
+
+   We thank Carsten Bormann, Brian Carpenter, Wendy Grossman, Kathleen
+   Moriarty, Jan Schaumann, Seth David Schoen, and Paul Wouters for
+   comments and review of this text, though that of course doesn't mean
+   that they necessarily agree with the text.
+
+   This document was created at the behest of Eliot Lear, who also cat
+   herded and did some editing.
+
+Authors' Addresses
+
+   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