RFC 7258 – Pervasive Monitoring Is an Attack

I'm going to have to disagree with you there. See, even without authentication, in a world of pervasive opportunistic encryption, Eve is pretty much screwed for spying on everyone's data, and we can cause trouble for a fair amount of metadata collection, too. And a pretty large amount of the pervasive surveillance infrastructure out there now relies quite a lot on the information gleaned just from being Eve.

So, you say, a Nation State Adversary will just switch to being Mallory and MITM all the things? Well, that might not be a choice they want to make. In a good protocol design allowing for opportunistic encryption, Mallory can't actually tell for sure if Alice and Bob are being opportunistic or not. That means Mallory has to guess whether they can safely run active interference without getting caught, or whether Alice or Bob are in a position to find out about it and, thanks to things like Certificate Transparency and others, loudly tell the world about it - and then Mallory's going to have to fend off awkwardly pointed questions about why exactly they're spying on Alice the source and Bob the journalist, or Carol the perfectly normal person and Dave their lover having webcam sex over Yahoo [hypothetical names; real GCHQ operation, search platform cover-named OPTIC NERVE].

Opportunistic Encryption techniques give us the opportunity to, with no configuration necessary, close the door on several of the easiest ways to be able to spy on everyone covertly. That's a big improvement from where we are right now. It forces a potential Nation State Adversary to weigh up carefully the risks of using such a capability, given they can't be certain to hide it: the more they use it, the more likely they'll get caught. So they can either act in the open, where everyone can see it, or choose to not act at all, or (most likely) act more selectively (which isn't perfect, but it's a start). That is a hard choice for many of them to make and potentially opens the door to actual discussion about oversight (or lack thereof), necessity (or lack thereof), usefulness (or lack thereof), and the incredible risks posed by such technologies' deployment.

I don't think there's a hell of a lot we can technically do about a pervasive determined well-funded doesn't-give-a-damn-about-anything jackbooted Mallory, using what I'll call constructive techniques (as opposed to destructive techniques, which, for example, actively disrupt surveillance infrastructure - which of course are, from the adversary's point of view, perfectly okay for them but highly illegal when you do it). That's not the threat we face in all places, however: the situation isn't hopeless, everywhere, yet.

As the BCP points out, we need non-technical (i.e. political, etc) solutions to this attack model too: this isn't a problem we can solve on our own. But piece by piece, we're doing what we can to combat this attack - and this BCP is a clear statement of the overwhelming IETF consensus that we do regard it as having a malicious impact on the internet as a whole, and that it's an attack we need to address every practical way we can.

Yay, a whole new class of protocols which will make it harder to communicate with each other.

I'm all for secure protocols but metadata protection is so nebulously defined, and introduces such ridiculous problems, that I really don't want it built into core protocols.

There is no solution to it - moving traffic from here to there via a third party requires telling someone how to do it. So long as that third party exists, the problem is unsolvable outside of distributed-risk models like Tor.

Oh. That's.. strange, but good to know. Thanks.

In your last paragraph, you've actually provided a good example of why opportunistic encryption is dangerous. Instead of deploying proper HTTPS, you're thinking that opportunistic encryption is good enough for you, that it is a valid replacement for HTTPS.