[OTR-dev] mpOTR project

[Ximin Luo]

On 18/12/13 13:08, Jacob Appelbaum wrote:
> 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.
> 

Why doesn't it count - because it can happen for plaintext too? That is the whole point. If you want to deny things in court, you have to be more strict. What is the point of being able to deny an OTR transcript, when you can't deny other evidence?

If you just provide your own USB drive with a log and claim it's the plaintext, that is not convincing. But if you seize the physical computer with its plaintext logs, that is more convincing. Likewise, anyone can forge an OTR transcript, but if you have ciphertext snarfed off the network by some top secret surveillance program, and you compromise one of the endpoints to recover the session key, that is more convincing.

Perhaps it's not feasible to provide strong deniability in that sense. I also understand that forgeable transcripts ("OTR-deniability") are necessary for strong deniability. But by itself, I don't see it as anything to boast about.

>> 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.
> 

That is confidentiality, which is separate from deniability. It enhances deniability only insofar as it's an additional layer the attacker needs to break through. If someone breaks your confidentiality, e.g. if your partner is compromised, your level of deniability is back to the plaintext case. So "no reduction in deniability" is accurate.

>>
>> 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.
> 

How is that a red herring? I'm just comparing use of language. You can treat me like an outsider who doesn't know all the contextual literature and connotations of "deniability". I have other connotations from the general society, then I come and read the OTR homepage which has that word. What am I going to think?

If you visit a website that claims to be "encrypted", but only the login page is "encrypted", what are you going to think?

>> [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
> 

Sure, that is good advice.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20131218/d6d0b1b9/attachment.pgp>