[messaging] Axolotl for email

[Wei Chuang]

Hi Tankred,

Thanks very much for the reply, and the pointers on where you folks are
going.

On 23 June 2016 at 03:39, Tankred Hase <mail at tankredhase.de> wrote:

> I’ve only seen this thread just now, so please excuse my late reply.
> Thomas from Mailvelope and me have been thinking about using the Signal
> protocol for email for a while now as well. FWIW there was a discussion
> about it during Q&A at a talk I held on email encryption lessons learned at
> whiteout.io and OpenPGP.js [1].
>
> I agree that there is value in bringing forward secrecy and a modern
> cipher suite to email.


Well more specifically that Axolotl will for a single pass authenticated
encryption pass to work (instead of traditional sign/encrypt passes in PGP
or S/MIME) as well reducing the need for revocation.


> But I also don’t see an easy solution to the multi MUA problem already
> discussed in this thread. Messages in Signal are ephemeral and stored on
> the user’s device. If those messages are deleted or lost that’s not a big
> issue for most use cases. This is why a forward secure protocol works well
> here.
>
> Email is a different beast entirely and requires storage of messages, in
> certain cases up to 10 years due to compliance requirements.

Even if the messages were stored only on a single MUA, there would have to
> be a backup of the mailstore on some server.


While I understand it's useful to think about the complete system and
multiple MUA case, and you point out it becomes easy to get tied into a
knot.  It may be easier to distinguish and partition transport vs MUA
protocols.


> Which would require a long lived key or passphrase for encryption. If you
> look at how WhatsApp handles long-lived storage, they basically delegate
> the issue to an optional iCloud/Google-Drive backup feature, which store
> data in the clear :/
>
> When people talk about using the Signal protocol for email, I think what
> they are mostly referring to is the painless user experience for key
> distribution. Which is why I think we should borrow UX concepts for email
> that have proven to work at scale for Signal. Our first attempt at this for
> Mailvelope is a very simple key server that allows reliable
> TOFU/auto-lookup (no key transparency included). We’re planning to launch
> integration in the Mailvelope extension in July.


I agree a key server is pretty hard to avoid especially when usability
becomes paramount.  I've been trying to follow the discussion about this IETF
draft <https://tools.ietf.org/html/draft-bhjl-x509-srv-00>.

-Wei


> More info and links to the code here [2].
>
> It’s still early days, but I’ve been showing the key server to others in
> the GPG/OpenPGP community like GPGtools and Enigmail and there is interest
> to use this concept to allow interoperability between our OpenPGP plugins.
> Nothing final yet though. Discussion and talks for key exchange are planned
> at the OpenPGP Summit in July [3] and probably also at OpenPGP.conf [4].
> Hope to see some of you there, so we can continue the discussion :)


> Tankred
>
>
> [1] https://www.youtube.com/watch?v=tcRPsWP6bEQ
> [2] https://keys.mailvelope.com
> [3] https://wiki.gnupg.org/OpenPGPEmailSummit201607
> [4] https://gnupg.org/conf/
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160627/b66e6b7b/attachment.html>