FWIW, I've partially answered some of my own questions. I'm replying to myself with some extra information for completeness:
George Kadianakis <[email protected]> writes: > 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. > > <snip> > > * 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? > On the topic of guaranteeing reliability and consistency in chat transcripts, it seems that Matthew Van Gundy et al. have been preparing a draft paper called "OldBlue: Causal Broadcast In A Mutally Suspicious Environment": http://matt.singlethink.net/projects/mpotr/oldblue-draft.pdf which is a Causal Broadcast protocol that is supposed (I think) to fit the needs of mpOTR. > * 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? > Matthew Van Gundy has been preparing a paper in this area too. His paper "Improved Deniable Signature Key Exchange for mpOTR" proposes to replace the suggested pairwise DSKE of mpOTR with a broadcast variant like "Deniable Group Key Agreement" scheme of Jens-Matthias Bohli et al. I think we shound also investigate whether we can replace other parts of the suggested mpOTR protocol with broadcast variants. > * 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 _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
