The way this happens today in the real world is that I send you an email with an encrypted zip file attachment (and I make sure I've chose an appropriately secure encryption method) then I call you (or meet you in person) and tell you the password.

Symmetric encryption has ergonomics which are actually easier than asymmetric encryption with the tools we have today.

You could associate your public key with a DNS record that you control?

e.g. https://tools.ietf.org/html/rfc7929

This is orders of magnitude more difficult than just telling someone to install Signal. Even people who are somewhat tech savvy are going to have trouble with these instructions. I freely admit that I have no idea how to do what you're proposing I do.

The MitM problem is not with sending the public key. They can just email it. The MitM problem is with intercepting the instructions from person A, having the MitM person generate them, and provide the pair to person B while impersonating A.

If you know you want to email [email protected] and if you trust DNSSEC, then fetching the public key for [email protected] from the DNS should be at least as secure as visiting https://example.dk in your browser.

(If you don't trust that Alice's email address is [email protected] then you shouldn't send an email for her to that address regardless of MitM attacks.)

> ... and if you trust DNSSEC...

I don't, thanks.

You're omitting the part that example.dk could create a fake key for [email protected], publish that, decrypt a copy for themselves, and reencrypt it for [email protected]'s public key.

Well, I said it's at least as secure as visiting https://example.dk in your browser, where your attack is equivalent to the hosting company or DNS provider generating a new TLS certificate for that domain without the knowledge of Alice, the nominal registrant. (The web PKI also has the problem that any CA can issue a certificate for any domain).

The catch is that the primary reason to choose encrypted email is to prevent your hosting email provider from reading your email, so the inability of encrypted email to provide that guarantee kind of renders it worthless.

Of all the attackers you could worry about, I wouldn't put your own email hosting provider at the top of the list. MTA-STS is nice, but it's hard for an email client to guarantee that the hop-to-hop links between itself and the recipient's inbox are going to be protected with TLS. Passive snoops between mail providers seem like a much more realistic threat.

Also, by putting a public key in the public DNS, it means that Alice can catch her mail provider's DNS server giving false information about her public key, which would come with cryptographically signed proof of which entities were involved in that lie. Ideally there would be an equivalent to the Certificate Transparency system for keys that are used or protected by DNSSEC.

I can also send you the commands to copy-paste into your terminal to generate the key pair and ask you to give me the public key.

That could def. be MITM’d though

That would have to be someone actively engaging in MitM and not merely listening and keeping record.

Even if that's the case though, you can raise the difficulty by doing it through a phone call.