On 5 June 2013 The Guardian published the first article drawn from the documents handed over by Edward Snowden, and over the three years that followed the community that standardises Internet protocols changed an underlying assumption: that the intervening network is a passive channel and not an adversary. This shift in the threat model has concrete technical consequences, legible in IETF documents, in server configurations and in withdrawn standards.

Context

The disclosures made public between June and October 2013 — PRISM, bulk metadata collection, the BULLRUN programme to weaken cryptographic standards, the submarine-cable tapping documented under the name TEMPORA — carry a political and legal weight that falls outside these notes. The technical point is narrower and more verifiable: the idea that an observer with access to the backbone cables is a realistic part of the threat model for a protocol in everyday use.

Until 2013 that assumption weighed little in the design of most application protocols. Cleartext traffic was the norm for non-transactional pages; HTTPS stayed confined to login and payment; reusing the RSA key for session exchange was common because it cost little. Each of these choices takes for granted that whoever sits between client and server does not record the traffic to analyse it later.

The change in threat model

The sharpest statement comes in May 2014 with RFC 7258, Pervasive Monitoring Is an Attack, published as Best Current Practice 188. The document says in a single sentence that pervasive monitoring is a technical attack, to be mitigated where possible in the design of IETF protocols. The word attack is the one that does the work: it places a mass observer in the same vocabulary used to assess an active adversary when standards proposals are reviewed. A working group that neglects pervasive-monitoring mitigation now has to justify the choice rather than take it as a given.

RFC 7258 introduces no mechanism: it changes the acceptance criteria. A proposal that exposes metadata reusable by a passive observer starts from a weaker position in the technical discussion. It is a process constraint, and its effects can be read in the protocol revisions published afterwards.

Forward secrecy as a default configuration

The most measurable consequence concerns key exchange in TLS. With classic RSA exchange the client encrypts the session secret with the server’s public key; whoever records the traffic and later obtains the private key can decrypt every captured session in retrospect. This is exactly the scenario of the observer who archives today to decrypt tomorrow.

Forward secrecy — obtained through ephemeral Diffie-Hellman exchange, in practice ECDHE over elliptic curves — removes that dependency: each session uses a temporary secret that never travels over the wire and cannot be reconstructed from the long-term private key alone. The property was known and available in TLS 1.2 (RFC 5246, 2008) well before 2013, but it stayed optional and often low in the order of cipher suites. Over the three years that followed it becomes the de facto recommended configuration: ECDHE at the top of the preference order, RSA exchange deprecated in hardening guides. The IETF work on the next TLS revision, still in draft status as of mid-2016, makes forward secrecy mandatory rather than optional.

Dual_EC_DRBG: from suspicion to withdrawal

The most direct case of a weakened standard concerns Dual_EC_DRBG, an elliptic-curve pseudo-random number generator standardised by NIST in SP 800-90A. A possible structural flaw had already been documented in 2007: Dan Shumow and Niels Ferguson had shown that the standard’s constants could hide a relationship known only to whoever had generated them, enough to predict the output. It stayed a theoretical suspicion, because evidence about the origin of those constants was missing.

The BULLRUN documents move that suspicion towards operational confirmation. NIST reopens the revision of SP 800-90A, gathers public comment and in 2014 removes Dual_EC_DRBG from the standard. It is the clearest illustration of the problem BULLRUN raised: a public standard, adopted in good faith by implementers who trusted the process, built so as to be weak for anyone who knew the hidden parameter. The technical response — withdrawing the standard and revising the process that produced it — is documented in the NIST record.

Lowering the cost of access to HTTPS

If forward secrecy and the withdrawal of Dual_EC_DRBG concern the quality of the encrypted channel, a second strand concerns its reach. Encrypting an isolated channel protects little if the rest of the web stays in cleartext: the passive observer still reads most of the traffic. The historical obstacle to universal HTTPS was operational — cost, manual renewal and configuration of X.509 certificates — more than cryptographic.

The Internet Security Research Group launches Let’s Encrypt as a free certificate authority, with automated issuance and renewal through the ACME protocol. After a public beta opened in December 2015, the service reaches general availability on 12 April 2016. The relevant effect is economic before it is cryptographic: it brings the marginal cost and operational friction of a valid certificate to zero, and with them one of the reasons a site stayed in cleartext. This is consistent with the RFC 7258 model — reducing the surface readable by a mass observer — without asking for any new cryptographic mechanism.

Funding the shared infrastructure

2014 also surfaces a problem independent of Snowden but handled by the same community. The Heartbleed vulnerability (CVE-2014-0160, April 2014) in OpenSSL makes it visible that a library underpinning much of the web’s encrypted traffic was maintained by very few people on minimal funding. The response was structural: the Core Infrastructure Initiative, hosted by the Linux Foundation, funds critical open source libraries; OpenBSD forks LibreSSL to simplify and clean up the codebase; independent audits increase. The point in common with the reaction to Snowden is a plain one: trust in a channel depends on the verifiability of the code that implements it, and that verifiability costs resources, not just open licences.

Limits

The changes described concern the transport channel and its reach, not the endpoints. Forward-secret encryption between browser and server does not protect data once it reaches the server, where collection programmes at the providers — such as those associated with PRISM — operate on cleartext data. The threat model formalised by RFC 7258 is that of the on-path observer; it does not cover legal or operational access to the endpoint, which remains a question of governance and jurisdiction more than of protocol.

The availability of a mechanism is also to be distinguished from its actual adoption. As of mid-2016 the share of HTTPS traffic is growing but far from total, many servers still expose deprecated cipher suites, and the TLS revision that mandates forward secrecy is a draft, not a published standard. The three-year trajectory can be read in the documents; its extension across the whole ecosystem is a process still under way.

Cover image: Edward Snowden in 2013, a head-and-shoulders portrait while speaking, a still frame from a video — photo by The WikiLeaks Channel, CC BY 3.0 — https://commons.wikimedia.org/wiki/File:Edward_Snowden_2013-10-9_(1)_(cropped).jpg