Attempting to bolt public key onto encryption is one of the many things that’s already been attempted multiple times. We can see from those attempts that it’s not worked, for a variety of reasons.
How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have?
How does the person rotate keys if we only talk occasionally?
Or, if we’re looking for a bigger, overall flaw: e-mail is fundamentally fire-and-forget via SMTP, so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.
Well, you could use opportunistic encryption: once the first (plain text) email is sent, it establishes an identity for the sender and from that point forward the exchange is encrypted. It's, of course, not authenticated, and anyone can MITM the exchange, but it kills dead all passive (eavesdrop only) attacks. Also it makes a past compromise easy to detect, without reusing any session key.
A more direct solution would be to leverage the DNSSec infrastructure and publish, say, an "MXK record" (MX Keyserver) for each compliant server. If such a record is present, then the mail domain vouches that you can find at that specific address a VKS keyserver that can resolve individual public keys for all its mailboxes. The whole exchange is encrypted and hierarchically authenticated, from the DNSSec root down to the individual mailbox, so it requires the cooperation/compromise of the specific level to break.
This way, when you type "user@host" in your email client's To: bar, the client can immediately resolve the public key of the recipient, and encrypt and sign the message accordingly with a high confidence that the encryption will be transparent and ensure the security of the exchange.
You’ve not addressed the overall problem of session vs long lived keys, but more so you’re pitching we tie this to DNSSEC? I’d think the fact that DANE is basically the same idea and has been jettisoned by browser vendors would be a good data point.
Long lived public keys work well for PGP, the trouble with that is the manual handling of keys and huge learning curve. With automated identities handled by the email client and countersigned by the provider, you can easily establish a key rotation schedule. Maybe not as effective as Signal but it stops all MITM attacks that don't compromise the providers, a high bar. Of course, the actual symmetric encryption key is unique for each message.
DANE was ditched not because of technical problems or political pushback, but simply due to lack of adoption. Massive network effects and existing investment in the broken CA model, sites don't care about interacting with two sets of PKI if customers will only reach them on one, therefore they don't publish DANE records, therefore the support is removed from major browsers after a few years essentially to reduce dead code and 1024 bit RSA keys. If you know otherwise please enlighten. So it's the same problem everywhere, lack of interoperability chains us to outdated protocols, a problem of course shared by my proposal too.
> How do I trust the public key I get via a tag in an email from somebody whose public key I don’t already have?
You trust it as much as you trust getting getting unencrypted email from your friends. The point, though, is that from then on, nobody else can eavesdrop on your communications with the person who sent you their public key. You can still verify it by calling up the person and asking if he sent it. Or you can have him send the key via snail mail.
> How does the person rotate keys if we only talk occasionally?
The same way you got the original key.
> so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.
Is it that massive? SSH uses keys that aren't changed every time it's used it, and it's still viable.
Besides, it's as secure as any public key cryptosystem is, and that's a heck of a lot better than plaintext.
SSH uses asymmetric crypto to authenticate, and then negotiates session keys. That’s how most modern PKI systems actually work. TLS is a great example: all actual traffic is encrypted symmetrically, and all modern ciphers use forward-secret session key negotiations.
And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure.
For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.
Yes, but anyone with my SSH keys can connect with SSH.
> but give the user an illusion that what they’re saying is secure.
I don't trust any encryption system with my life or the nuclear launch code. But for casual privacy, the scheme I proposed is fine.
> I’m using your old key, the one I have
Then my system should bounce it back saying the key is invalid. Of course, if I change my key the email app should send a "new public key" email to my address book.
I said long-lived keys for data encryption is a pitfall, you pointed out SSH uses long-lived keys, I said it doesn’t use them for data encryption, and now you’ve just said an unrelated true thing about SSH?
There’s a huge valley of users between “casual privacy” and “nuclear launch codes”. Most humans live there. If your pitch is that your system is a casual privacy tool, just use email. Casual threats aren’t doing dragnet email surveillance or hacking email providers.
> If your pitch is that your system is a casual privacy tool, just use email
The lock on my front door is easily circumvented by anyone determined to get in. But we still use door locks, and locks are far more effective than otherwise.
My proposal is ridiculously simple. All it requires is to standardize a single tag in the email protocol which provides a public key and agrees on a particular public key method. That's it.
Email apps can support it, or not, it still works. Even if just gmail supported it, or Thunderbird, or Outlook, it will be viable.
An Email is not analogous to a house, it's more akin to a tent, or a lean-to; A simple solution to a simple problem.
Tent: How can we build a serviceable shelter that can be quickly un/packed, built, and costs next to nothing?
Email: How can we enable everyone to send messages to everyone else with as little inconvenience as possible?
Both solutions solve the stated problem, and that's it. If I want a secure shelter, a tent alone will not suffice, I have to build a ditch&wall around it. Similarly, if I want secure communication, I have to encrypt the message before sending it via Email.
SMTP is not made to be secure, because that's not the problem domain it concerns itself with.
