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

[George Kadianakis]

FWIW, I've partially answered some of my own questions. I'm replying
to myself with some extra information for completeness:

George Kadianakis <desnacked at riseup.net> 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
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev