[OTR-dev] mpOTR protocol phases and research questions

[David Goulet]

On 23 Oct (08:26:59), George Kadianakis 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

I'm wondering if there is at least *one* case that is documented where
deniability has been used in court (or in a legal way)? Will it even
stand in court? Apart from that legal use case, is there any need for
deniability?

I'm no crypto expert but my understanding is that deniability with OTR
done by broadcasting the ephemeral keys after usage, any entity with
some ressources (let say here a government) could make some time
correlated attack with a set of clear text logs and the OTR packets.
What I mean here is that with mpOTR, the chance that someone in the
discussion is compromised is higher because 3 or more parties are
involved making the attacker able to correlate OTR messages with the
logs especially in a public channel on a public server for instance.
Achieving that, I don't see a scenario where deniability could be used
in a legal way.

Considering that, if correct, I feel like deniability seems a non
trivial part here for very little gain especially if we have to advise
to use mpOTR in a NON public channel.

Again I might be wrong, Thoughts?

Cheers!
David


>   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.
> 
> 
> 
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: Digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131023/d0b39c91/attachment.pgp>