Please do encrypt all the things. It may take some more years of engineering to lock things down to the extent a new HeartBleed isn't always happening, but it's worth the effort.
One citizen's lolcats should look just like another citizen's rebellion.
For what it's worth, I had to use https: to check that from my phone because my provider uses a HTTP transparent proxy (otherwise known as a man-in-the-middle!) - and it's down. (How very unfortunate. Perhaps it should know better than to try and parse my traffic.) And you had a certificate signed by your own CA, and that's no real bother when the link was http: in the first place. I was only able to read your blog because you used OE. Poetic.
But I know that every connection I make, GCHQ is a passive MITM on at least one hop. That's more pervasive than a coffee-shop Wifi - and they can inject things into plaintext traffic, too.
You think DANE's going to be a problem? I don't think so. It's at least as good as domain-validated certs with a CA - which isn't very good, but it's a reasonable minimum. It helps with pinning.
tedu: TLS/PGP/GPG software is a minefield, so don't use it everywhere.
me: TLS/PGP/GPG software is a minefield, so let's investigate alternatives. Either something will stick, or TLS/PGP/GPG will be pressured to substantially improve. Or both.
I think tedu may agree with me because he's involved in signify, an OpenBSD tool to cryptographically sign/verify files, and reop, an alternative to OpenPGP software like GnuPG.
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
Also, side channel attacks are hard, so let's just use plaintext.
The reason encrypting things is nice is that it reduces the attack surface. You only have to protect your email at the point of consumption. Taken to extremes, if PGP were ubiquitous then your IMAP account wouldn't need to have a password.
I don't understand what would make someone think that possibly-compromised security is worse than no security.
False sense of security - you think your communications are secure but they're not.
You are never 100% secure. And probably don't want to be even that close to 100% (cost being too great).
This is pretty much where I come down on the issue. I don't really care if anyone reads my email 99.5% of the time. I know it's not very secure, so I don't use it for communicating anything I care too much about. Encyrpting all my email strikes me as about as sensible as using a one-time pad to encrypt postcards I send when I'm on vacation.
If I need to PGP something, I use the command line to create an ascii-armored version of the message and I copy/paste it into the email. I don't integrate PGP with my email client, even though that option is available to me. For the few times a year I need to deal with encrypted email, it's just not worth it.
But I honestly don't know which approach is better in lieu of TFA; however I'm leaning towards encrypting (almost?) everything.
P.S. Someone above me mentioned, bugs and complexity only get noticed and fixed if there are enough people using encryption, and I think that's a great point too.
I don't think I understood the other half of the article.
(Full disclosure: my startup surrounds certificates and PKI)
In fields of specialized knowledge, we aim to render an account that is plain and simple, yet does no violence to the difficulty of the subject, so that the uninformed reader can understand us while the expert cannot fault us. We try to keep in mind a saying attributed to Einstein that everything must be made as simple as possible, but not one bit simpler.
(In case it's not obvious, this is sarcasm using the same reasoning as the article.)