[messaging] Axolotl for email

[Wei Chuang]

On 9 June 2016 at 11:45, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:

> On Thu 2016-06-09 14:16:02 -0400, Wei Chuang wrote:
>
> > Would it make sense to apply Axolotl for email encryption?  While the
> > protocol allows the D-E exchanges to be asynchronous, the main remaining
> > issue is the initial D-E exchange setup.  TextSecure uses pre-keying, but
> > that likely has challenges for email as there isn't a standard directory
> > service for email.  Are other approaches possible?  Would it be possible
> to
> > use existing PKI (X.509 or PGP based) to transmit the initial D-E key
> with
> > integrity?
> >
> > If that can be overcome, I see the following advantages (and please
> correct
> > me if I'm wrong):
> > 1) Perfect forward and backwards secrecy makes key loss much less
> > important.  So much so that much of the worry about key revocation goes
> > away.
> > 2) Message processing needs only be a single pass authenticated
> encryption
> > encrypt/decrypt that provides both privacy and integrity.  S/MIME and PGP
> > would have to do two passes and would have weaknesses as described here:
> > http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
> >
> > Assuming that it does make sense is there standardization work for
> Axolotl
> > for email encryption?  I've read about the OMEMO for XMPP that is
> related.
> > If so, who is a contact for the Axolotl email standardization work?
>
> I'm interested in this idea, but i haven't had any time to work on it.
>
> I see two challenges for the simplest case (pairwise, single-sender
> single-recipient e-mail):
>
> a) signalling that such an arrangement is possible between the two peers.
>
> b) synchronizing the complex and changing keystore (pairwise state
>    between all correspondents) between multiple e-mail clients, since
>    many people use multiple MUAs to access a single mailbox
>
> (i suppose you could punt on (b) for an initial implementation)
>
> I'd say bootstrap off of existing key material would be the way to go,
> though, and use standard MIME encryption to handle the misery that is
> required when dealing with e-mail structuring.  For example, if you use
> PGP/MIME, you'd just replace the existing PKESK (public key encrypted
> session key) packet with some specially-tagged session key packet that
> the peer would detect and use as a prompt to access their keystore.
>

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.


>
> Anyway, i'm interested, if you want to bounce design ideas off of
> someone, i'm game.
>

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.

-Wei


>
>    --dkg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160610/e4f0174c/attachment.html>