Nadim Kobeissi <[email protected]> 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 <[email protected]> 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! _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
