[OTR-dev] mpOTR protocol phases and research questions

[George Kadianakis]

Here are some more notes about mpOTR that I refreshed today.

Here are some properties that the mpOTR protocol should have. These
were also mentioned in the mpOTR paper:

- Confidentiality
- Entity Autentication
- Origin Authentication
- Forward Secrecy
- Deniability (Repudiation/Malleability)
  Do we want this? It would certainly be nice to have, but it makes
  things so much harder!
- Transcript synchronisation
- ...

Here is a breakdown of an mpOTR session in phases:

[Channel establishment] -> [Authentication] -> [Key exchange] ->
[Communication phase] -> [Shutdown phase]

At the moment, the [Authentication] and [Key exchange] phases are the
ones that need the most attention from researchers. More details
below.

Phase breakdown:

[Channel establishment]
* Where a set of initial unauthenticated participants is selected and
  a channel between the participants is established.

Notes:
- I assume that the protocol is centralized since it makes
  everything much easier (I assume that broadcast happens by
  sending a broadcast msg to a server). We can decentralize
  later.

Solutions:
- Assuming an application-agnostic protocol, this can happen using IRC
  channels, or XMPP MUCs, or SIP or whatever.

[Authentication]
* Where participants authenticate each other and a set of
  authenticated participants is established.

Notes:
- At the end of this phase, each participant should be confident
  that he trusts all the other authenticated participants.

- If deniability is in our goals, this handshake should happen in
  a deniable fashion.

- A session ID etc. must be established somewhere around here too.

Solutions: Possible solutions include:
- "Improved Deniable Signature Key Exchange for mpOTR" by Matthew Van Gundy.
  Uses the scheme presented in "Deniable Group Key Agreement" by Bohli
  et al as a basis.
  The Bohli paper is not terribly well-cited.
  Also see
http://lists.cypherpunks.ca/pipermail/otr-dev/2013-August/001815.html

- Just-Vaudenay "Authenticated multi-party key agreement". Well-cited,
  but there are published attacks (key-compromise impersonation etc.)
  against the original protocol. The idea is kind of similar to the
  2-party key exchange proposed by Trevor Perrin in:
  https://whispersystems.org/blog/simplifying-otr-deniability/

- The protocols mentioned by Matthew Van Gundy in:
  http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html

- There are dozens more protocols that we haven't looked at. Which
  ones are worth reading? GDH.2 and GDH.3 by Steiner et al.?

[Key exchange]
* Where participants negotiate a shared key to be used for this
  conversation.

Notes:
- This phase will probably get merged with the "Authentication
  handshake" phase using a "Authenticated Group Key-Exchange
  protocol".

- Ideally this handshake should be friendly towards dynamic
  groups, so that the computational damage of joins/parts is
  minimized (with a naive scheme, this handshake will need to
  be repeated everytime someone joins or leaves the channel).

- This handshake should be cheap and ideally broadcast-based.
  Handshakes that work pairwise between participants are expensive and
  hard to scale.

Solutions:
- See the previous section for "Authenticated Group Key-Exchange"
  solutions.
- Also see "Secure group communicaton using key graphs" and "Scalable
  Authenticated Tree Based Group Key. Exchange for Ad-Hoc Groups" for
  dynamic group key-exchange solutions.

[Communication phase]
* Where participants, using the derived keys, communicate with each
  other in an authenticated/confidential fashion.

Notes:
- A message format must be defined. Each message will need to be
  encrypted, authenticated, maybe even marked with a sequence number,
  etc. Also see the mpOTR paper for more stuff that we need to be
  aware of.

- Furthermore, we need to ensure transcript correctness, that is,
  in real-time fashion each participant should be assured that
  she is seeing the same transcript as all the other
  participants. This is to avoid attacks like:
  """
  [PoV of Alice]
  Bob: Do you like reggae music?
  Alice: Yes!
  Bob: Do you like metal music?
  Alice: No!

  [PoV of Bob]
  Bob: Do you like reggae music?
  Alice: No!
  Bob: Do you like metal music?
  Alice: Yes!
  """
  To avoid this we will need to use some kind of causal delivery
  protocol. For example, "OldBlue: Causal Broadcast In A Mutually
  Suspicious Environment" by Matthew Van Gundy et al.?

[Shutdown phase]
* A shutdown phase might be needed in a deniable protocol so that
  parties expose their ephemeral keys etc.
* A shutdown phase is needed in any case to memwipe all cryptographic
  material from memory.

Notes: The mpOTR paper includes a Shutdown() algorithm.