[OTR-dev] mpOTR protocol phases and research questions

[George Kadianakis]

Nadim Kobeissi <nadim at crypto.cat> writes:

> I've replied to George inline, so please read that first, but I also have some side-points:
>

Hey Nadim!

> 1) We should not forget to discuss the issue of synchronous vs. asynchronous messaging. As David Goulet and Jurre once pointed out, we really should take mpOTR as an opportunity to make the chat protocol asynchronous, so that it's more widely implementable. The synchronous aspect of OTR right now is a huge pain for regularly interrupted session scenarios, like mobile chat and for example Twitter DM.
>

Yes, that's a good point. Ideally mpOTR should work nicely in volatile
environments -- like when moving between WiFi APs. To be honest, I
haven't thought of how the mpOTR protocol should look like if we
wanted this design goal.

(Dynamic-group key exchanges (like tree-based ones) would certainly be
helpful though)

> 2) I want to point out that we should make sure that the mpOTR protocol we end up with is easy to implement and accessible to multiple platforms. This is both to widen accessibility and adoption, and to prevent implementation errors by people who don't specialize in crypto but want their iPhone app to have secure group chat.
>

I agree. Excessive cryptowankery should be avoided.

> On 2013-10-23, at 5:26 PM, 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!
>
> From what I know, I really think deniability is not worth considering as a property. As we saw in the Manning court case, the issue of deniability wasn't even brought up. We're not going to be teaching judges math, not in the US and definitely not in Syria and Iran, where people get prosecuted over false chat logs all the time. Deniability was an interesting property to introduce in the original OTR paper, and it made the paper more attractive, but it's not worth carrying on. I think much more interesting properties would be things like forward secrecy.
>
> There's also a lot of agreement on this from the crypto community, example:
> https://twitter.com/matthew_d_green/status/392721028591677440
>

I'm also of the opinion that deniability is making protocol design,
reasoning and implementation harder. And really, I don't know of any
occasions where deniability has been used in a court of law either.

That said, I don't think that deniability is stupid. On the contrary,
I think it's a very interesting property.

To be honest, I also used to think that deniability should just be
removed from the goals of mpOTR, since it's bullshit and we would have
a much simpler protocol that could be implemented today. Here are some
thoughts that made me believe in deniability a bit more:

a) A neat (zero-knowledge) deniable protocol would not leak the
   identities of its participants. Assuming that the protocols
   underneath it don't leak either, it might allow completely
   unlinkable communications between parties.  I think.

b) Deniability has been researched much more than I originally
   thought. Protocol papers with "deniability" in their title have
   been floating around for decades [0]. There are many more deniable
   group key exchanges and deniable authentication protocols than I
   initially thought there were. And also:

c) Deniability *might* be easier than expected. The implicit DH-based
   protocols that Trevor has been talking about are good
   examples. From a first glance, I don't think they require
   complicated shutdown() procedures either.

d) Many smart people have thought of deniability and still believe in
   it. (Of course, symmetrically, many smart people have thought of
   the deniability problem and still find it a joke.)

e) Reducing the number of signatures coming from your private keys is
   always good. (OTR fails this)

(PS, maybe one day courts will *have* to take deniability
seriously. This might happen with time as technology gets even more
important and even more deniability-related cases get investigated. Or
it might happen if people try to *force* the courts to take
deniability seriously by forging conversations of people that the
courts want to protect. In any case, I wouldn't be surprised if
deniability is never taken seriously for "important" cases like the
one you cited.)

(PS2, we can't really talk about "mpOTR" if we don't include
deniability. The protocol stops being "Off The Record".)

As a closing note, I must say that my opinion on deniability is
continuously changing as I spend more time thinking about it. I'm
really not sold to it at the moment, but I don't believe it's stupid
either. I also wouldn't say no to a non-deniable secure multiparty
chat; especially if someone convinced me that it's design is *much*
simpler than its deniable version.

[0]: From a small survey I've done, the first paper that mentions
   deniability is the "Concurrent Zero-Knowledge" paper by Dwork et
   al.

>> 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.
>
> I had a meeting with Bruce Schneier recently and one issue that was discussed was deniability and authentication in the multi-party context. Bruce felt that deniability was not a necessary property in the multi-party context (something which I fully agree with). Regarding authentication, Bruce recommended that we always go back to real-world scenarios when envisioning solutions to problems of authentication; “how would fifty people in a room authenticate each other in real life?” He implied that no easy solution could be expected for cryptographic authentication problems for which no convenient, easy real-life model existed. Worth a thought, eh?
>

(FWIW, I also think that deniability is not a *necessary* property
either. It would be certainly be fun to have though.)

Reducing the mpOTR authentication problem to "how would fifty people
in a room authenticate each other in real life?" seems like a good way
to think of this.

Going back to some of the edge cases I mentioned in:
http://lists.cypherpunks.ca/pipermail/otr-dev/2013-February/001611.html
I wonder what would happen in a real life room when:

- 50 people try to authenticate each other and suddenly everyone
  believes that one person is an impersonator. What do you do? I guess
  you probably take the other 49 people and move to your own room (and
  hope that the impersonator cannot find where the new room is).

- 50 people try to authenticate each other. Some people believe that X
  is an impersonator but other people believe that X is cool and the
  impersonator is actually Y. What do you do? (This can actually
  happen if some people have the old public keys for X and Y.)

- 50 people are in a room. Another person enters the room. No one
  knows him. After a while, 49 people authenticate him as legit (maybe
  they added his fpr to their keychains). Still, there is one person
  who hasn't authenticated the newcomer and is just zoning out looking
  at the wall (maybe he is AFK and he hasn't answered the 'validate
  fpr' dialog box). What do you do? Do you move everyone and the
  newcomer to a new room? Or do you reject the newcomer? Or what?

I can make more such stupid scenarios very easily.

(Also, who moves people around the rooms? This requires knowledge of
the underlying chat protocol (IRC, XMPP, etc.), or rekeying to a
subset of the original participants.)

Cheers!