Greetings, this is a post about mpOTR and secure multiparty chat protocols in general. I'm very interested in the secure multiparty chat problem, and I _really_ want to see it moving forward.
A thing that confuses me about the latest "let's complete the mpOTR spec" campaign, is that when I read the mpOTR paper I see some nice formalizations of the secure multiparty chat problem and a collection of ideas that multiparty chat protocols can use in the future. For example, the Threat Model section of the paper proposes some reasonable ways of thinking about the security of chat protocols. On the other hand, when I read the mpOTR paper, I really don't see a robust protocol that is waiting to be spec'ed and implemented. As a matter of fact, I think we are still a long way from a scalable secure multiparty chat protocol. The other day, I posted a brain dump in github about things that confuse me when I think of multiparty chat protocols (and mpOTR): https://github.com/ioerror/mpOTR/issues/6 Today I decided that mailing lists are a much better platform for such discussions, so I tidied up my thoughts a bit and posted them here: * Is mpOTR supposed to be pluggable (like OTR) into current chat frameworks, like XMPP or IRC? Section 4.1 of the paper thinks so. How does the security of the underlying chat framework, influence the security of mpOTR? For example, if we use standard XMPP to setup mpOTRed MUCs, the owner of the room can kick and mute people, and mpOTR can do nothing about this. When does a "secure" chat protocol (like mpOTR) require a "secure" chat framework? * Is the shutdown phase of OTR the only place where transcript soundness is guaranteed? By 'transcript soundness', I mean the guarantee that all participants see the exact same transcript. What happens, if an 3vil server drops packets in the middle of the conversation? Do participants learn this only in the end of the conversation? * What about the tree-based transcript soundness idea that was discussed in FOCI '12? Is that also necessary in server-based chat frameworks (like XMPP and IRC), or only in decentralized environments? Is mPOTR centralized or decentralized after all? * Why do the primitives of mpOTR have to be pairwise between participants? This makes the protocol ugly and hard to scale. Aren't there ways to do group-key-exchanges in a "each-party-broadcasts-something-and-the-whole-group-creates-a-group-key" fashion. I think there are fields of cryptography (like "Conference key distribution" and "Group key exchange") that deal with this kind of thing. Why are we not using them? * Based on the previous question, how much do we want the protocol to scale? Do we want 5 people to be able to talk to each other, what about 40? What about 200 people or even 1000? * I will briefly mention deniability and the Fundamental Problem of Deniability (as presented in the mpOTR paper). It seems to me that deniability gives people a sense of security which might be completely useless in real life courts. It also complicates the protocol by an insane amount (Deniable Signature Key Exchange, complex shutdown phase, etc.). I know that some people here like the deniability property of mpOTR a lot, but personally I would be very happy with a multiparty chat protocol with end-to-end confidentiality, authentication and PFS, even if it didn't provide deniability in its first version. (FWIW, I like deniability and I would love to have a multiparty chat protocol that supported that property. Unfortunately, at the moment we have no multiparty chat protocols, and deniability is making their research and development even harder.) * Having cryptographers design the mpOTR protocol is great, but we will also need people who are experienced in thinking about chat protocols to evaluate whether our protocols are usable, deployable and scaleable. We should involve people from the XMPP and IETF community in this endeavor; they actually care about this problem, but they have many other things to care about and they are not cryptographers. * It's ridiculous how many edge-cases a simple chat protocol produces. Let alone a chat protocol with specific security properties. For example, 15 people talk in a conference, and suddenly an extra person gets invited. If the extra person is unknown to some people of the existing conference, do these people have to validate the fingerprint of the new guy? What happens if one of those people is AFK? Similar silly edge-cases really confuse me when I think about secure multiparty chat protocols. For this reason, I was thinking of writing a document similar to "Fallacies of Distributed Computing". It would be an article about assumptions that people take when they design chat protocols. For example, "all peers know each other beforehand", "all peers stay for the whole duration of the conversation", "all peers leave at the same time", etc. Maybe this way, it would be easier for people to reason about such edge-cases. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
