<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 9 June 2016 at 11:45, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu 2016-06-09 14:16:02 -0400, Wei Chuang wrote:<br>
<br>
> Would it make sense to apply Axolotl for email encryption?  While the<br>
> protocol allows the D-E exchanges to be asynchronous, the main remaining<br>
> issue is the initial D-E exchange setup.  TextSecure uses pre-keying, but<br>
> that likely has challenges for email as there isn't a standard directory<br>
> service for email.  Are other approaches possible?  Would it be possible to<br>
> use existing PKI (X.509 or PGP based) to transmit the initial D-E key with<br>
> integrity?<br>
><br>
> If that can be overcome, I see the following advantages (and please correct<br>
> me if I'm wrong):<br>
> 1) Perfect forward and backwards secrecy makes key loss much less<br>
> important.  So much so that much of the worry about key revocation goes<br>
> away.<br>
> 2) Message processing needs only be a single pass authenticated encryption<br>
> encrypt/decrypt that provides both privacy and integrity.  S/MIME and PGP<br>
> would have to do two passes and would have weaknesses as described here:<br>
> <a href="http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html" rel="noreferrer" target="_blank">http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html</a><br>
><br>
> Assuming that it does make sense is there standardization work for Axolotl<br>
> for email encryption?  I've read about the OMEMO for XMPP that is related.<br>
> If so, who is a contact for the Axolotl email standardization work?<br>
<br>
</span>I'm interested in this idea, but i haven't had any time to work on it.<br>
<br>
I see two challenges for the simplest case (pairwise, single-sender<br>
single-recipient e-mail):<br>
<br>
a) signalling that such an arrangement is possible between the two peers.<br>
<br>
b) synchronizing the complex and changing keystore (pairwise state<br>
   between all correspondents) between multiple e-mail clients, since<br>
   many people use multiple MUAs to access a single mailbox<br>
<br>
(i suppose you could punt on (b) for an initial implementation)<br>
<br>
I'd say bootstrap off of existing key material would be the way to go,<br>
though, and use standard MIME encryption to handle the misery that is<br>
required when dealing with e-mail structuring.  For example, if you use<br>
PGP/MIME, you'd just replace the existing PKESK (public key encrypted<br>
session key) packet with some specially-tagged session key packet that<br>
the peer would detect and use as a prompt to access their keystore.<br></blockquote><div><br></div><div>Agreed.  The heart of the work is to figure out what sort of key and other metadata needs to be passed to between the parties in a way that's compatible with PGP (or CMS).  The other important technical bit I still think is the initialization.  </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, i'm interested, if you want to bounce design ideas off of<br>
someone, i'm game.<br></blockquote><div><br></div><div>Sure.  As to the direction of this idea, my first thought was make sure there isn't an idea like this already in progress and to sanity check the application of Axolotl i.e. what this email is about.  Second step is to brainstorm the idea.  One venue is IETF 96 Berlin in a BOF type thing.  Another place might be a shared doc.  Ultimately I think a good (if not idealized outcome) is to document the result in the IETF e.g. RFC.  If other folks want to implement, feel free. </div><div><br></div><div>-Wei</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
   --dkg<br>
</font></span></blockquote></div><br></div></div>