Re: Why are mail servers not also key servers?

[Viktor Dukhovni <[e-mail]>]

On Thu, Apr 20, 2017 at 07:01:05PM +0200, Jon wrote:

> 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.

A major problems with all E2E email encryption proposals is unrelated
to key distribution, none of the extant MUAs provide an adequate
interface for E2E encrypted email.

      + Encrypted email is not searchable.

      + Encrypted email is difficult to scan for spam and malware

      + Changing the private key can mean loss of access to email
	encrypted under the old key.

      + Signatures stop verifying when the signature key expires,
	even though they were valid at the the email was received.

In addition, nobody is investing any effort into major improvements
in standalone MUAs.  Free webmail has gotten rather fancy, but
content security is not in the provider's interest.  Will users
want to pay for security that reduces usability?

Therefore, for the foreseable future, hop-by-hop TLS is the best
security you're likely to get, and is most appropriate for the
vast majority of email.

It is not enough to invest effort in better key distribution,
the effort will be wasted unless the right incentives are in
place to induce a similar effort in usability of E2E encrypted
email after it arrives.

> > 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.

TLS is quite sufficient to guard against passive monitoring, and
the final message stored unencrypted in the user's mailbox is much
more usable.

Make (stored) E2E email usable, and then there'll may be real
incentives to address key distribution.  Otherwise, any effort
to address key distribution will be largely wasted.

Do you have a design for an efficiently searchable and yet secure,
encrypted content index that supports concurrent updates from
multiple clients without losing data integrity?

How do you propose to handle spam and malware?

-- 
	Viktor.