[OTR-dev] Thinking about mpOTR and secure multiparty chat protocols in general

[George Kadianakis]

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.