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 <m...@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@moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging >
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
