[Avamander]

> Acquiring keys, rotating keys, identifying compromised keys, and most importantly either reaches a large enough percentage of emails sent that usage of it is not in itself an immediate flag to monitor or can be implemented as a side channel not directly including the signature in the email payload itself.

You are describing S/MIME?

[ISV_Damocles]

Kinda. But S/MIME has its own problems[0], mostly related to you as a recipient being unable to choose who is authorized to send you encrypted email (and so spam and malware filters don't work).

On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand. Handing a payload of data to a third party that the recipient can eventually query to retrieve makes it much easier to grab a hold of and try to decrypt in the future. The same is true of SSL to an extent, but SSL traffic is much more voluminous, such that saving all of it to eventually crack and decide if there's anything worthwhile in it is unlikely.

The only real way to transfer private data between two users is to do it live with an ephemeral channel, whether that's in-person or via SSL or etc. The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.

[0]: https://en.wikipedia.org/wiki/S/MIME#Obstacles_to_deploying_...

[Avamander]

> mostly related to you as a recipient being unable to choose who is authorized to send you encrypted email (and so spam and malware filters don't work).

That's a problem with all encryption anyways. Inspection has to be done at the end-user's device. So I don't think it's fair to hold that against S/MIME.

> On top of that, GPG and S/MIME's support of encrypted-at-rest email is, imo, a fool's errand.

If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.

> The only value I see in GPG and friends is in verifying authenticity of the contents - signing the email - not encrypting those contents. Email has, and always will be, an open protocol, for better or worse.

To some extent I agree. An ubiquitous deployment of digital signatures would already solve a bunch of problems and most of the rest are handled by transport encryption.

[ISV_Damocles]

> That's a problem with all encryption anyways. Inspection has to be done at the end-user's device. So I don't think it's fair to hold that against S/MIME.

I don't think that has to be the case, though. Protocol negotiation is a thing; SSL negotiating the version of the protocol to use, HTTP 1.1 -> 2.0 negotiation, etc.

You could imagine a mail protocol that starts at an encryption level, then during the negotiation process when the mail-to-be-delivered provides a public key, the recipient server can check that key against a listing of keys accepted by the user, and if not included, attempt to negotiate down to an unencrypted version of the email.

The sender of the email could choose to not allow that downgrade and get an undeliverable mail error, or they could choose to allow the downgrade to plain text/html email. This could then be run through the standard spam/malware filtering as usual and the spam eliminated, while email that came from already trusted email can skip those filters because the user has already judged them worthy of accepting and keeping the communication private.

So I don't think that's an intrinsic difficulty of all encryption schemes for email, but...

> If it can be done with E2EE messaging apps, sure it can be done with email. Long-term storage is a really difficult problem anyways.

So first I'll state that I don't think all E2EE messaging apps reach the following bar, either, but the difference between an ephemeral SSL-encrypted communication channel and an email, fundamentally, is that the ephemeral channel won't be written to a disk somewhere, while the email will.

The window in which it is possible to get a copy, and the difficulty in obtaining it, is much more in favor of secrets staying secret in the ephemeral channel than it is in encrypted email. The data payload persists longer, and is likely encrypted by the same private key across many emails, so getting the emails and getting the keys are much easier than with the ephemeral channel that generates a temporary set of keys on each connection and never persists any of it to disk (so storing the communication with the hope of eventually grabbing the keys from the user's machine by virus or social engineering or just plain ol' physical theft doesn't even make any sense the same way GPG-encrypted email does).