[messaging] Email obstacles and experiments

[Wei Chuang]

This is just some initial thoughts.  I don't as much as I should about
Pond, so hopefully a better response later.

On 12 June 2016 at 16:31, Trevor Perrin <trevp at trevp.net> wrote:

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

Yes I have to agree those are significant issues with email based
encryption and I don't have answers really to these.  My goal as you
mention was to tackle a small part of the problem i.e. the efficiency side
of encrypted email.  To motivate why its still worth pursuing encrypted
email, I'll point out that the alternative to federation is vendor lock
in.  While things may move quickly initially in a closed model to acquire
users, there's no guarantee once a vendor has that captive population that
they'll be inclined to continue innovating.


>
> I'd think more about problems like:
>
>  * The coordination problems with adding new features to a federated
> protocol [1]
>

MAAWG is one path. Another path is the motivation of the providers to save
money i.e. if the technique does improves efficiency.  A third yet is to
opensource the code into a commonly used library such as openssl to
accelerate adoption.


>  * Handling spam and abuse when content is encrypted [2]
>

Agreed this is huge issue.


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

Agreed.


>
> 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.
>
>
I like this idea because notions of recipient identity i.e. whose mailbox
to forward to is determined by the recipient SMTP.  This is important in
figuring out the profile.  This may even better handle forwarding.  One
complication is that AFAIK SMTP doesn't have a notion of priority, so
adding this lookup in the compose path could slow that down, and even if it
does traditional SMTP processing is slower due to spam processing etc.
Regarding step 2, I would assume the message is signed to resist MitM?
Perhaps that could be used to create a fast path.


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

Let me just point out a draft that's in discussion current:
https://tools.ietf.org/html/draft-bhjl-x509-srv-00
that uses WebPKI for integrity.


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


Yeah.  I'll have to think some more to come up with a more coherent
response.

-Wei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160613/7f79c1d1/attachment.html>