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 [
RFC 7687] in 2015, but in the meantime, work proceeded on a BCP document codifying that the IETF community considered that "pervasive monitoring is an attack" [
RFC 7258] (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 [
RFC 8446] 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) [
RFC 7858] or DNS Queries over HTTPS (DoH) [
RFC 8484], 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 [
RFC 9113] and QUIC [
RFC 9000] 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) [
RFC 8461].
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 [
RFC 7217] [
RFC 8064] [
RFC 8981].
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 [
RFC 1984]. 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.