On 20/04/2017 16:29, Yoav Nir wrote: >> *SNIP* > I’m sure such things have been considered in the past, and for certain > SMTP could be extended. I can think of a few complications right of the > top of my head. There are undoubtedly others: > > 1. People use multiple MUAs. For this account I use this Mac MUA, a > phone MUA, and occasionally the web-based MUA. I’d need to share the > private key to receive encrypted mail on all three. Doing it in the > browser is a hard problem. > This is why I think smtp should be extended. All your mail agents support (E)SMTP and presumably they would all support an extension to smtp. The private keys will need to be stored some how to allow for multiple clients, but a key generated from user input could be used to decrypt a stored copy of the private key. > 2. There’s the administrative problem of tying the SMTP server to > whatever server is serving the public keys. HTTPS from the same IP > address? New special DNS SRV record somehow tied to the gmail.com > <http://gmail.com> MX record? > Indeed there is an administrative problem. I've done a project I call CMTP that takes a very federated, hand off stance on this to keep administration down. https://github.com/darakian/cmtp tl;dr servers have keys and sign transactions. The server key is simply requested and is trusted on first use. > 3. How much to you trust your email provider? Because they could > trivially serve the wrong public key and intercept your traffic. > I really dislike this argument. You, me, and many others already trust our mail servers in the same capacity. Sure a mail server could serve the wrong key and then my mail ends up in a nefarious villains hands, but that is already the case today. If there's some degree of confidentiality we at least have traffic interception as a possible case rather than the default. Jon
Attachment:
signature.asc
Description: OpenPGP digital signature