[messaging] Axolotl for email

[Nadim Kobeissi]

This is indeed a nice idea.

OMEMO would in theory handle the concerns DKG mentioned (signaling and keystore), but that depends on how we can integrate this information into the transport layer that is email. OMEMO attempts to integrate this into the XMPP transport layer and thus has a very XMPP-specific data structure.

XMPP is explicitly modular, which is what allows OMEMO to be elegantly published as an XEP. Email is only implicitly modular. How much control do we have over an email's header, as clients? Depending on the  answer to this question, we could integrate signaling and a pointer to a dedicated key server handling key information within the email header, by essentially translating the OMEMO data structure from XMPP XML to a set of email headers. In terms of long-term and ephemeral secret key storage, you'd of course have to engineer a special plugin to create that keystore for the local email client.

Axolotl over email might actually also have advantages to Axolotl over WebSockets/XMPP/IM: Due to the much lower exchange rate in email, a smaller number of hash chains might need to be stored locally by each user in order to avoid reliability issues. For example, Signal and Cryptocat both currently store the last five hash chains of a conversation in order to prevent decryption errors from occurring in case one party is operating on a particularly shaky Internet connection or messages are received very out-of-order.

Conversely, this forward secrecy also disallows users from re-decrypting any ciphertext they've sent in the future, once the ratchet state updates sufficiently to remove non-fresh key shares. PGP has no forward secrecy and thus can decrypt emails from ten years ago with no problem. I wonder how we can make this difference clear to users.

I would also be happy to work on this as I am well-experienced with implementing OMEMO and find this a suitable use-case.

Nadim (sent from ThinkPad)

________________________________________
From: Messaging <messaging-bounces at moderncrypto.org> on behalf of Daniel Kahn Gillmor <dkg at fifthhorseman.net>
Sent: Thursday, June 9, 2016 8:45:37 PM
To: Wei Chuang; messaging at moderncrypto.org
Subject: Re: [messaging] Axolotl for email

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.

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

   --dkg