<div dir="ltr">This is just some initial thoughts. I don't as much as I should about Pond, so hopefully a better response later.<br><div class="gmail_extra"><br><div class="gmail_quote">On 12 June 2016 at 16:31, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Thu, Jun 9, 2016 at 11:16 AM, Wei Chuang <<a href="mailto:weihaw@gmail.com">weihaw@gmail.com</a>> wrote:<br> > 1) Perfect forward and backwards secrecy makes key loss much less important.<br> <br> <br> Currently, email encryption has poor useability and little adoption.<br> Adding forward secrecy seems like trying to run before we can walk.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br> I'd think more about problems like:<br> <br> * The coordination problems with adding new features to a federated<br> protocol [1]<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * Handling spam and abuse when content is encrypted [2]<br></blockquote><div><br></div><div>Agreed this is huge issue. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * Handling spam and abuse when senders are anonymized (e.g. Pond-like systems)<br> * How to make native email clients that attract users away from webmail<br> * Business models that would support large-scale email providers,<br> aside from web ads<br> * How the webmail functionality people are used to (server archive,<br> server search) can coexist with encryption<br> <br> I don't know if those problems are solvable. If you want to try, I<br> think you'd need to approach them incrementally and experimentally:<br> build things, see what works, iterate.<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br> Is it possible to lower the cost of these experiments? I'll toss out<br> an idea, but I'm not sure it's good:<br> <br> ---<br> <br> Imagine extending mailservers so that users can publish an "encryption<br> profile" containing public keys (or URLs and hashes of public keys).<br> Mailservers would treat the user's profile as an opaque blob, so that<br> users could publish any combination of (for example) PGP keys, S/MIME<br> certs, or other data.<br> <br> The flow would be something like:<br> <br> 1. Recipient's mail client contacts her mail server and publishes<br> her "encryption profile". Whenever she changes a public key, she<br> publishes a new encryption profile. If she stops using encryption,<br> she deletes her profile.<br> <br> 2. Sender starts composing an email to Recipient. If Sender's mail<br> client doesn't have a cached encryption profile for Recipient, then<br> Sender's mail client contacts Sender's SMTP server and asks it to<br> fetch Recipient's encryption profile from Recipient's SMTP server.<br> (We do this lookup through the same SMTP path that we send the<br> message, so that it has the same security. If we used a different<br> path, like fetching keys from DNS, or PGP keyservers, then there's<br> more risk that bad profiles could disrupt communication.)<br> <br> 3. Sender's mail client encrypts the mail based on the profile, if<br> it recognizes data in the profile (e.g. if the Sender's client<br> supports PGP, and the profile contains a PGP key).<br> <br> 4. Sender adds a header indicating which encryption profile it used<br> (e.g. a hash value). If the Recipient's encryption profile has<br> changed, Recipient's SMTP server rejects the mail and sends back the<br> new profile, and Sender's client re-encrypts and re-sends (and<br> probably displays a key-change warning to the Sender).<br> <br> 5. Recipient's client downloads the encrypted mails via POP/IMAP.<br> If the Recipient also has legacy clients that don't understand<br> encryption, the mailserver won't show them the encrypted mails.<br> <br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br> So this would make mailservers into simple keyservers. You might want<br> keyservers with more features, e.g. handing out one-time prekeys for<br> forward-secrecy, with authentication and rate-limiting so it's not<br> easy to drain all the prekeys. It would be easy to add a URL for such<br> a keyserver into your profile.<br></blockquote><div><br></div><div>Let me just point out a draft that's in discussion current:</div><div><a href="https://tools.ietf.org/html/draft-bhjl-x509-srv-00">https://tools.ietf.org/html/draft-bhjl-x509-srv-00</a><br></div><div>that uses WebPKI for integrity.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br> This doesn't address the problem of encrypted spam and viruses<br> bypassing server-side content scanning. We'd probably need additional<br> server-side mechanisms for that (e.g. [3]) before email encryption<br> could be deployed at large scale.<br> <br> But a profile mechanism might at least be useful for small-scale<br> experiments, and for figuring out how bad the spam/abuse problems<br> really are.<br> <br> <br> Trevor<br> <br> [1] <a href="https://whispersystems.org/blog/the-ecosystem-is-moving/" rel="noreferrer" target="_blank">https://whispersystems.org/blog/the-ecosystem-is-moving/</a><br> [2] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000780.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000780.html</a><br> [3] <a href="https://moderncrypto.org/mail-archive/messaging/2015/001524.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-archive/messaging/2015/001524.html</a></blockquote><div><br></div><div>Yeah. I'll have to think some more to come up with a more coherent response.</div><div><br></div><div>-Wei <br></div></div><br></div></div>