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. 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. 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. [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. > 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" - 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*. [1] http://tools.ietf.org/html/draft-riikonen-silc-spec-09 [2] http://tools.ietf.org/html/draft-riikonen-silc-ke-auth-09 [3] http://tools.ietf.org/html/draft-riikonen-silc-pp-09 -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
