Re: Why are mail servers not also key servers?

[Jon <[e-mail]>]

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