On Thu, Jun 9, 2016 at 11:16 AM, Wei Chuang <wei...@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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
