[OTR-dev] mpOTR project

[Jacob Appelbaum]

Ximin Luo:
> On 17/12/13 20:56, Jacob Appelbaum wrote:
>> Ximin Luo:
>>> However, *even if you achieve it*, I would still strongly propose
>>> that we stop calling it "deniability" or "off-the-record", for
>>> the "misleading-users" reasons I detailed elsewhere.
>> 
>> Generally speaking, we discuss protocols in terms of repudiation
>> and non-repudiation. The word deniable is a mapping of common
>> understanding with the less than common meaning of the word
>> repudiation.
>> 
> 
> I'm fine with equating repudiable/deniable; my complaint was instead
> directed at using these labels without any sort of qualifier. There
> are lots of non-cryptographic information leaks, which make certain
> forms of OTR transcripts non-repudiable in a court.
> 

Such as? Adium logging OTR plain text to the disk doesn't count here.

> As I mentioned elsewhere, "no reduction in deniability (compared with
> plaintext chat)" is more appropriate. However, to call OTR simply
> "deniable", "repudiable", "off-the-record" or any similar thing,
> implies that it has an *advantage* in this area over plaintext chats,
> when it does not.

The OTR (SOUPS, etc) papers very clearly says these things.

OTR does have an advantage over plaintext chats - they are encrypted and
when someone sniffs them, even if they are unauthenticated, that someone
is locked out of the content of the conversation.

> 
> By contrast, the (theoretical[1]) plausible-deniability property of
> a censorship-resistant publishing platform like Freenet *does* have
> an advantage over plaintext storage - since the node operator doesn't
> have the keys to decrypt the documents he is hosting, he cannot be
> held responsible for them.
> 

That is a red herring if there ever was one, Ximin.

> [1] yes, I'm aware that in practise Freenet probably has holes; my
> argument is abstract. You can replace "Freenet" with the theoretical
> "Eternity service" if that makes you more comfortable.
> 

The key here is that these abstract arguments are made by simply
ignoring the practical and abstract benefits of OTR.

>> SILC exists for group chats if you want an encrypted multi-party
>> chat protocol with non-repudiation (in a court, from a forensics
>> perspective, etc etc).
>> 
>> If people are going to re-invent SILC, why not ensure that they
>> don't make the same mistakes?
>> 
> 
> I only heard about SILC today, but browsing the RFCs[1][2][3], I
> don't see mpOTR as simply "SILC with deniability". SILC has these
> deficiencies compared to mpOTR:
> 
> - end-to-end encryption is optional and not well-specified
> [1#section-5]: "if the client requires .. not trusting any of the
> servers .. it can be accomplished by negotiating private secret keys
> outside the SILC Network"

Yeah, it's like a channel key in irc - only the key provides end to end
encryption for all parties in the channel. This protects that chat
channel from a snooping server.

> 
> - message source authenticity is also an afterthought
> [3#section-2.3.2.6]: "This flag indicates that the message is signed
> with sender's private key .. A separate document should define
> [this]." This is consistent with the security section [1#section-5]
> omitting that clients might not trust *each other*.

It isn't an afterthought, it was an option - it shows that most of this
discussion is a rehash. It was a mistake to ever allow clients to sign
messages in a non-repudiated fashion. Why repeat that mistake?

Other than reading the specs, you might try using it? SILC has lots of
issues but it actually exists. We should ensure that new protocols that
provide similar properties are an improvement over past attempts to
solve the encrypted group chat problem.

All the best,
Jacob