For more than a decade, the web security field was plagued by vulnerable UX that would, in a bunch of different ways, shift users off HTTPS sites and on to HTTP sites. It was a real problem, only recently and gradually mitigated by HSTS.
Two distinctions to draw between the HSTS situation and the encrypted email situation:
1. There is no proposed "HSTS" for email, let alone any coherent plan by which it could be rolled out; HSTS worked because a very small number of browsers needed only collaborate with a relatively small number of server operators to make it work; the dynamics of email are totally different.
2. In the web threat model, the consequences of shifting a user from HTTPS to HTTP are not automatically fatal, and affect only that user. In the Inevitable Encrypted Reply, whole threads involving multiple counterparties are disclosed. And in the PGP threat model, you have to assume the adversary is recording everything, all the time. Once the I.E.R. happens, you and all your friends are dead.
Thank you for fleshing out the comparison between HSTS and encrypted email. I just have a couple of points to add.
1. For the avoidance of doubt, there is a proposed "HSTS for email", but it doesn't provide end-to-end encryption (so it's not particularly relevant here). The technology I'm talking about is MTA-STS,[0] as described in RFC 8461, which you probably already know about, but it might be new to other people.
I'm not sure how different the dynamics are between the web and email, though. Surely there are more operators of web servers than email servers? Also, over 90% of the email client market is attributable to Google, Microsoft, Apple, and Yahoo! collectively.[1] That doesn't seem very different to the situation with browsers.
2. I think it's worth highlighting that if a user is shifted from HTTPS to HTTP, that may mean that their password (or session cookie) is being sent unencrypted to/through an attacker. Once the attacker has this, they can access all the details of a user's account, which, in the case of webmail or a forum, includes all previous messages and grants them the ability to send new messages as that user.
That seems like a worse failure mode than just losing the privacy of a single message, and I think people are just as likely to die if you leak information about them over insecure email as over insecure HTTP. In both cases the threat model would assume that the adversary is recording everything, all the time.
Right, so, in the world of secure messaging, there's nothing in the world less trustworthy than a public Internet email server, and MTA-STS doesn't change that; it makes dragnet surveillance of email harder (and does something else you & I will disagree about) and is a good thing, but doesn't change the comparison here at all. What is needed is a mechanism that ensures that a secure exchange between two people never suddenly becomes plaintext email exposed to any server.
With respect to the comparative failure modes: a single accidental plaintext reply can expose dozens of participants. If we're not LARPing, if we're seriously talking about protecting people organizing against state-level security services, we have to confront the sheer blast radius of that mistake, which happens all the time even to people who routinely use PGP'd email.
Further: if the premise is that our adversaries have state-level resources, we have to assume they're recording all the time. You can't accidentally send plaintext ever. There's no takebacks if you do. It's irrevocable. If your email group sees a plaintext quote-reply, you have to grab your go-bag, thermite your hard drive, and make your way to the border, right now.
Once again: this is a mistake that people who well understand encrypted email make all the time.
It is irresponsible to encourage at-risk people to use PGP-encrypted email. It's malpractice.
I think I'd agree with most of what you said there. I would only reiterate that the expected blast radius of leaking a single plaintext email is likely to be less than that of leaking a password/session over HTTP (assuming the user is in possession of comparably sensitive information in the two scenarios).
Of course, on the modern web, the latter failure is much less likely to happen, and I accept your point that PGP encrypted email is uniquely burdened by the risks of backwards incompatibility, at least in the world of secure messaging services. It may not be a perfect comparison for me to bring up HTTPS, but I think that the incremental nature of that technological upgrade provides some helpful perspective.
Also, I appreciate your restraint about what I assume is the other subject that would be a source of disagreement. There's no need to complicate matters by introducing that extra topic, and I apologise if mentioning MTA-STS was unhelpful for that reason.
Two distinctions to draw between the HSTS situation and the encrypted email situation:
1. There is no proposed "HSTS" for email, let alone any coherent plan by which it could be rolled out; HSTS worked because a very small number of browsers needed only collaborate with a relatively small number of server operators to make it work; the dynamics of email are totally different.
2. In the web threat model, the consequences of shifting a user from HTTPS to HTTP are not automatically fatal, and affect only that user. In the Inevitable Encrypted Reply, whole threads involving multiple counterparties are disclosed. And in the PGP threat model, you have to assume the adversary is recording everything, all the time. Once the I.E.R. happens, you and all your friends are dead.