The mpOTR paper is not enough to design a secure chat protocol

[asn-d6]

Greetings people,

I'm very interested in this subject and I've been thinking about it for the past some months. Specifically, if cryptocat hires someone competent to think about this, I would be very interested in meeting with that someone and helping him/her design the protocol.

I see that currently you guys are spending your brain cells and time fighting about licensing issues. Well done.

Here are some questions that trouble me when I think of multiparty chat protocols. They are not well articulated or structured here, but it might give you an idea of the troubles that are head of us (and that it actually requires lots of thinking and protocol deisgn, and not simply cryptographic sk1lls).

• Is mpOTR supposed to be pluggable into current chat frameworks, like XMPP or IRC? If yes, 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 that has nothing to do with mpOTR. Can I invite other people to an mpOTR chat room? 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 fact that all participants see the same exact transcript. What happens, if a bad server drops stuff in the middle of the conversation? Do people 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 necessary even 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? That makes the protocol hard to scale. There should be ways to do group-key-exchanges in a "each-party-broadcasts-something-and-the-whole-group-creates-a-group-key" fashion.
• 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 here, and how the Fundamental Problem of Deniability (as presented in the original mpOTR paper) gives people a false sense of security and deniability, while it is probably useful in real life courts. It also complicates the protocol by an insane amount (Deniable Signature Key Exchange, wtf...).
• Having cryptographers design the mpOTR protocol is a good idea, but we will probably also need people who are experienced in looking at chat protocols to evaluate whether the protocol is usable. We should involve people from the XMPP and IETF community in this endeavor.
• Have you really thought of all the possible edge-cases that a chat protocol produces? In my experience, designing simple chat protocols is easy, but then you start thinking about the many possible edge-cases that can occur during a chat session with N people. For example, 15 people talk in a conference, and suddenly an extra person gets invited or gets in the group. 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?

[asn-d6]

Some additions:

• There is a field of cryptography called "Conference key distribution" which basically tries to tackle the problem of deriving group keys in conferences in an authenticated manner. All the current protocols are quite complicated and use stuff like "protocol compilers", but I think that it's a field worth exploring.
• I've talked with some XMPP people who are interested in this subject, and I know how to contact them. If you are interested in seriously bringing them into the game, send me a PM. But I wouldn't want to involve them if our main contribution to the world of secure chat continues being pages of fighting between kaepora and ioerror.
• Are you familiar with "Fallacies of Distributed Computing"? I would like to write a similar document 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.

Errata:

• In my previous post, "while it is probably useful in real life courts" should read "while it is probably useless in real life courts".