[OTR-dev] mpOTR project

[Dennis Gamayunov]

On 17.12.2013 21:06, Ximin Luo wrote:
> On 17/12/13 16:33, Dennis Gamayunov wrote:
>> Hi, Ximin,
>>
>> 17.12.2013 19:41, Ximin Luo пишет:
>>> Haven't had time to read through the wiki yet, but just wondering,
>>> what are your ideas on deniability? Some of us want to drop this
>>> property because it's really not that strong[1], and requiring it
>>> makes other parts of the protocol harder / more complex. Because of
>>> this, we also intend to drop the name "mpOTR", on the basis that
>>> deniability and "off-the-record" can be misleading for a non-technical
>>> user. X [1] see the otr-users thread, "The effectiveness of
>>> deniability", starting Nov 29, last message December 06.
>> I was not on that list, but similar subdiscussions occured here on
>> otr-dev as well.
>>
>> For me personally deniability is the mpOTR' primary difference from
>> various older secure chats (i.e. SILC, PGP-backed XMPP). If the
>> resulting protocol lacks this feature, I would expect new projects to
>> come to fill this niche. So, why don't we try to address the need of
>> deniability right now, while the protocol development is still in progress?
>>
> As we've been talking about "mpOTR", would provide forward secrecy (not the case for PGP) and be end-to-end decentralised (not the case for SILC).
>
> What's your user scenario where you find OTR-deniability to be useful? You understand that if your partner (who is logging your ciphertext) is colluding with the NSA (who is logging everyone), there is no "deniability" that you could argue in court? (IANAL)
Which arises the question - what's our adversary model for deniability?
What are the most (potentially) frequent usecases for "we can reject a
strong claim"? There is a wide variety of possible situations from "we
need to pin this guy, let's look what he has on his laptop", which may
be untargeted and accidental, to "we need to force this guy to say
something so that we could use his words as a proof later", which is
always targeted and hard to address with any kind of communications. If
we recall the basic idea of OTR communications, the protocol aims at
simulation the real-world scenario of off-the-record offline meetings,
and in this case global surveillance agent would be out of scope, won't it?

>
> OTR-denability is "we can reject a strong claim (a proof)". Intuitive deniability would be "we can strongly reject a claim", including metadata (hard!). Another alternative is "we can strongly claim (prove) the rejection", which is probably impossible, but I mention it for completeness, because some people get confused between the forms.
"We can strongly claim the rejection" seems impossible, indeed. But is
this really so, can we prove that somehow?
>> It's true that there might be very little practical difference between
>> "digitally signed proof" and "proof with a broken digital signature" in
>> some of the real-world scenarios. But maybe we could address these
>> scenarios in some other way? For example, during the shutdown phase we
>> are free to change the session transcript in arbitrary way, and
>> communicate it between participants. These manipulations could add bogus
>> messages into the transcript, or rework it so that user profiles in
>> terms of language use would be identical, or enforce some other
>> characteristics of transcript.
>>
>> Maybe it would be possible to keep the transcipt sceleton intact, to
>> make it accessible and searchable for the user off-line, but modify in a
>> way that would render impossible for the 3rd party to use it as a proof
>> of anything.
>>
>> Dennis
> You can't guarantee that others will follow protocol and edit the transcript in that way, similar to how you can't guarantee that your partner isn't logging the plaintext.

It seems you can guarantee some of these if the conversation is split
into a series of "sessions" in terms of the protocol, with full session
shutdown, transcript rewrite and rekeying based on negotiated rewritten
transcript. The typical conversation lasts for minutes, tens of minutes
and longer. Can we make very short communication phase which would last
for seconds, and make the shutdown and rewritten transcript negotiation
transparent for benign participants?