When not to Encrypt

I'm publishing this as an unfinished draft because it came up in conversation. Hopefully, I'll go back and rework this later. If you're not a technical person, just skip this one.

In technology circles, there's been a lot of talk about encryption lately. It's regarded as A Good Thing. If you take away one thing from this post, it's that encrypting your data is almost always a good idea. And, if you're not a technical person, you can just shorten that to "Always Encrypt".

But, for the techncal people, there are edge cases. There are always @#$!@% edge cases.

There are two primary reasons to encrypt: privacy and verification. Unfortunately, when it comes to TLS, they're mixed together. Verification is always a good thing, but there are times when the privacy is either unnecessary or actively harmful. For example:

1. Waste. If you're downloading a public file, and you have another way to verify it, then encryption is just wasted memory and processing power. That's not a big deal for most people. For a large datacenter, that 1-2% difference is noticeable. For a very poor school running old computers or low-cost devices like the Raspberry Pi, encryption is a much bigger hit: it's the thing that makes the computers slow. If you're downloading something like a signed OS patch, the OS will check the file integrity later, so there's no reason to waste the resources encrypting and decrypting it for the trip across the network.
2. Known Plaintext Attacks. When you encrypt data, you want to avoid encrypting known data because it gives an adversary something to look for. If Microsoft releases a 2.1GB Windows update, that day, millions of people will connect to https://update.microsoft.com and download approximately 2.1GB of data. Everybody who can see the encrypted traffic knows exactly what was downloaded. On a smaller scale, the login page of every service on the web is a small, known size. Anyone who can intercept that data stream can look for weaknesses in the encryption implementation. That's not a problem today, but it's often the first crack in the encryption wall as protocols age. [FIXME: I think this was a genuine problem with the Kerberos 4 protocol, and K5 moved a bunch of data to cleartext to remediate. Research.] 
3. Caching. Caching becomes much more difficult with current encryption implementations. There are ways to do it, involving basically subverting every machine in the organization with an internal CA so that a central proxy can act as a man-in-the-middle (and that's actually a legal necessity in certain industries in certain countries), but it's ugly. If there was a way to contact the central server to say, "I have a local proxy offering a copy of this page. Is it legitimate?", that would make it far easier for companies or even ISPs to offer proxies to their customers.

Just to get it out of the way, one deeply flawed argument against encryption is "...but terrorists". Spy agencies want to be able to catch terrrorists, which is a good thing. Unfortunately, there is absolutely no way to encrypt things for the good guys but not encrypt for the bad guys (or vice versa). It doesn't exist. 

How would I fix all of these problems? I'd create a standard way to query a webpage to say "Please provide a signature for the contents of this page WITHOUT sending the contents?" In my head, I think of it as HTTPV (for "Verified HTTP"), but it probably makes more sense to handle this with something like a new HTTP verb. Once that exists, you also need a way to inform the browser about optional proxies. [FIXME: Is this something that could be handled by WPAD? Research.] 

It's not easy, and it's not a short term plan, but in the long term, it could make the web a bit faster and a bit safer.