[Shendare]

I am a layperson, so the answer is probably painfully obvious, but why can't e-mail have TLS-style key exchange, where the sender's server gets the public key from the recipient's server and encrypts the message with it before sending it over?

The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key.

Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails.

But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.

[boneitis]

You could, but you're dropping the qualification of end-to-end encryption.

Brainstorms of a (mere) hobbyist:

Some might reason that that yields additional hardening to traditional TLS-enabled webmail applications.

On the other hand, that is more architectural design and work shifted away from the endpoints (and wasted, complex efforts with no added benefit if improperly implemented by the provider).

[boneitis]

One more brainstorm,

The provider can serve key escrow and still have the end-user application perform the encryption, which may or may not technically qualify. It certainly wouldn't fly without skepticism in a popular service/standard.

I haven't looked into it deeply enough to present a confident statement either way.

[austincheney]

The keys don’t come from the servers but from the end users, so the remote server won’t have the remote user’s key.

> Or they could let their provider hold onto a copy of the private key

Then the key is no longer private. The idea of a private key is not to share or distribute it.

[Shendare]

Why can't somewhere.com have the public key for [e-mail] and serve it to other e-mail providers on request?

Letting one's provider hold onto the private key doesn't provide the same level of security as the user being the only one with it, but it's a helluva lot better than not bothering with encryption at all.

Private keys can also be protected with a password, right? So the provider could have a copy of the private key but not the password to utilize it. The user would just have to never forget the password as opposed to never losing their private key to a hard drive failure or whatever.

[austincheney]

> Why can't somewhere.com have the public key for [e-mail] and serve it to other e-mail providers on request?

They could, but then somebody would have to deliberately request it. That would also mean adding a separate transmission/protocol different from the email protocols routing the messaging. That is a more streamlined process, but still not fully automated.

The only way to ensure adoption is to force onto users as an automated check of the primary protocol like the handshake of TCP. Even then you should still have to account for SPAM and anonymous users you don't want to exchange keys with.

Yes, private keys can be issued with a password. That is not an excuse to disperse your private keys though, because that password can be brute forced and then a criminal can access any account using that key set provided they aren't further blocked by something like 2 factor authentication. The password is just there as added security for things unintentional disclosure or unintended access, but not as a primary means of security.