Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?"

In particular, architectural decisions, including which existing technology is reused, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making architectural decisions.

Of course, the authors of this proposal are not oblivious to the fact that there might be a bit of resistance to this "Trust us" concept. So, for example, the proposal includes the assumption of mechanisms for users to opt-in or opt-out of these "trusted proxy" schemes.

But it's easy to be extremely dubious about what this would mean in the real world. Can we really be assured that a carrier going through all the trouble of setting up these proxies would always be willing to serve users who refuse to agree to the proxies being used, and allow those users to completely bypass the proxies? Count me as skeptical.

And the assumption that users can even be expected to make truly informed decisions about this seems highly problematic from the git-go. We might be forgiven for suspecting that the carriers are banking on the vast majority of users simply accepting the "Trust us -- we're your friendly man-in-the-middle" default, and not even thinking about the reality that their data is being decrypted in transit by third parties.

"You and I have limited resources, and the surveillor has limited resources -- maybe more than we have -- but if millions of users of the internet raise the bar a little bit, the requirements to surveil every little bit of internet traffic would be much higher," he explained to RNW.

The IETF's plans also benefit people who are already encrypting their online activities themselves, argued Marco Hogewoning, technical adviser to RIPE NCC. According to him, these people currently stick out like a sore thumb to the very surveillors they hope to evade.

"If you see an armoured car now on the street, you know there must be something valuable inside," Hogewoning explained. "If everybody drives around in an armoured car, I can go around and put a lot of effort into breaking into each and every car, and hope I get lucky and find something valuable inside, but it might be empty. If everybody encrypts everything, all you can see is armoured cars."

While the IETF might be able to secure the pipes through which users' data travel, users must also be able to trust the parties where their data is stored: software, hardware and services such as Cisco, Gmail and Facebook. These parties can hand over user data directly to government agencies.

NSA employees participated throughout, and occupied leadership roles in the committee and among the editors of the documents

...

Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto.

...

The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically".

In other circumstances I also found situations where NSA employees explicitly lied to standards committees, such as that for cellphone encryption, telling them that if they merely debated an actually-secure protocol, they would be violating the export control laws unless they excluded all foreigners from the room (in an international standards committee!).