[messaging] Email obstacles and experiments

[Trevor Perrin]

On Thu, Jun 9, 2016 at 11:16 AM, Wei Chuang <weihaw at gmail.com> wrote:
> 1) Perfect forward and backwards secrecy makes key loss much less important.


Currently, email encryption has poor useability and little adoption.
Adding forward secrecy seems like trying to run before we can walk.

I'd think more about problems like:

 * The coordination problems with adding new features to a federated
protocol [1]
 * Handling spam and abuse when content is encrypted [2]
 * Handling spam and abuse when senders are anonymized (e.g. Pond-like systems)
 * How to make native email clients that attract users away from webmail
 * Business models that would support large-scale email providers,
aside from web ads
 * How the webmail functionality people are used to (server archive,
server search) can coexist with encryption

I don't know if those problems are solvable.  If you want to try, I
think you'd need to approach them incrementally and experimentally:
build things, see what works, iterate.

Is it possible to lower the cost of these experiments?  I'll toss out
an idea, but I'm not sure it's good:

---

Imagine extending mailservers so that users can publish an "encryption
profile" containing public keys (or URLs and hashes of public keys).
Mailservers would treat the user's profile as an opaque blob, so that
users could publish any combination of (for example) PGP keys, S/MIME
certs, or other data.

The flow would be something like:

  1.  Recipient's mail client contacts her mail server and publishes
her "encryption profile".  Whenever she changes a public key, she
publishes a new encryption profile.  If she stops using encryption,
she deletes her profile.

  2.  Sender starts composing an email to Recipient.  If Sender's mail
client doesn't have a cached encryption profile for Recipient, then
Sender's mail client contacts Sender's SMTP server and asks it to
fetch Recipient's encryption profile from Recipient's SMTP server.
(We do this lookup through the same SMTP path that we send the
message, so that it has the same security.  If we used a different
path, like fetching keys from DNS, or PGP keyservers, then there's
more risk that bad profiles could disrupt communication.)

  3.  Sender's mail client encrypts the mail based on the profile, if
it recognizes data in the profile (e.g. if the Sender's client
supports PGP, and the profile contains a PGP key).

  4.  Sender adds a header indicating which encryption profile it used
(e.g. a hash value).  If the Recipient's encryption profile has
changed, Recipient's SMTP server rejects the mail and sends back the
new profile, and Sender's client re-encrypts and re-sends (and
probably displays a key-change warning to the Sender).

  5.  Recipient's client downloads the encrypted mails via POP/IMAP.
If the Recipient also has legacy clients that don't understand
encryption, the mailserver won't show them the encrypted mails.


So this would make mailservers into simple keyservers.  You might want
keyservers with more features, e.g. handing out one-time prekeys for
forward-secrecy, with authentication and rate-limiting so it's not
easy to drain all the prekeys.  It would be easy to add a URL for such
a keyserver into your profile.

This doesn't address the problem of encrypted spam and viruses
bypassing server-side content scanning.  We'd probably need additional
server-side mechanisms for that (e.g. [3]) before email encryption
could be deployed at large scale.

But a profile mechanism might at least be useful for small-scale
experiments, and for figuring out how bad the spam/abuse problems
really are.


Trevor

[1] https://whispersystems.org/blog/the-ecosystem-is-moving/
[2] https://moderncrypto.org/mail-archive/messaging/2014/000780.html
[3] https://moderncrypto.org/mail-archive/messaging/2015/001524.html