[OTR-dev] mpOTR project

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

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

-------------- 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/e52ee43c/attachment.pgp>