[OTR-dev] mpOTR protocol phases and research questions

[Callme Whatiwant]

On Wed, Oct 23, 2013 at 8:26 AM, George Kadianakis <desnacked at riseup.net> wrote:
> 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.

I'm not sure what this actually means.  Can we rephrase it to be more specific?

The only protocols I know of that "should make me confident that I
trust another participant" involve tweaking my body chemistry or
neural function.

Do you mean to say at the end of this phase, a participant has some
session state (such as a shared pairwise secret) which is
authenticated to another party's public key?  Do you mean something
else?


> - 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.
>
>
>
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev


cheers,
nejucomo