[OTR-dev] mpOTR project

[Jacob Appelbaum]

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?

It doesn't count because a key point for OTR is to ensure that the
plaintext on your disk is the best that anyone can get when you use OTR.
That is to say that we do not augment the logs with signature data. The
OTR'ed transcripts are just like transcripts that were not OTR. Most
logging programs don't even note if the transcripts were the product of
an OTR chat or not, for example.


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

Convincing of what? I can create logs for chats that we haven't had - I
can even put them in the right folder structure. That doesn't pass the
sniff test for proof - it is circumstantial evidence without
cryptography. It is a text file on a computer.

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

For the record, I have not seen evidence that OTR is broken by any
surveillance program.

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

Previous to OTR, people used PGP and IM programs, if they did anything
at all, I might add. Consider the improvement?

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

It is also confidentiality and confidentiality provides some deniability
in this case. This is confusing but deniability in the social sense is
fuzzy.

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

There are a few reasons. One is that we do not know if a person will be
held responsible. In some jurisdictions, a government may request a
decryption or the production of a key and failing to do so is a crime in
itself. Another is the difference between a chat between n parties and
keeping some ciphertext around for a long time.


>  You
> can treat me like an outsider who doesn't know all the contextual
> literature and connotations of "deniability".

I'm not treating you like an outsider, I'm asking you to read the
documents about the topic because you are a member of the larger
anonymity, security and privacy community.

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

That you may deny the specifics of a conversation.

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

If the claim is made with the TLS protocol, I'd look to see how the
cipher suite negotiation progressed - if it was indeed encrypted and
strongly authenticated, I'd think well of 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.
>>> 
>> 
>> 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.
> 

SILC has major problems in my view but ironically, other than the client
side implementation bugs, it is way way better than IRC or some web
based chat system.

All the best,
Jacob