[pkg-otr-team] Bug#766936: [libotr5] Extended description: "Deniability" is not a feature per se

[Filipus Klutiero]

Hi Harlan,

On 2014-10-26 23:08, Harlan Lieberman-Berg wrote:
> On Sun, 2014-10-26 at 21:22 -0400, Filipus Klutiero wrote:
>> Rather than advertising 2 independant items, these could be merged in a
>> "Deniable authentication" item which would contain both sublists.
> One reason why I think "deniability" is important as a separate feature
> is that it is differentiating in the face of other, similar kinds of
> programs.  Most encryption systems are not deniable; in fact, many
> systems are not deniable /by design/.  This message, for example, is PGP
> signed and is not deniable at all.  Anyone who gets a copy of the
> message can verify that I, or someone with control over my private key,
> composed and sent this message.  The Pidgin-Encryption plugin similarly
> doesn't have deniability built into its threat model at all.

I agree it is an important feature...
>
> In that context, I think it might be deserving of being listed as its
> own feature.

I didn't mean it doesn't "deserve" being listed on its own. What I meant is that I consider it a subfeature of authentication, so I find it confusing to see it independent from authentication. Grouping would make it more understandable.
>
>> By the way, I do not understand what "Anyone can forge messages after a
>> conversation to make them look like they came from you." means.
> It's part of the deniability feature.  While it's very difficult for an
> attacker to forge a signature while the conversation is going on, the
> ephemeral key used for signatures is publicly revealed after the
> conversation is over.  That means that you could forge any messages, and
> theoretically, provide some defense against someone who /did/ manage to
> compromise the communication being able to prove that you said what you
> said.
>

Thank you, I now understand what this sentence is about.

I am not convinced this is a good thing, but for sure the current phrasing is incorrect. According to the technical paper, OTR would merely send the key to the other participant, so only him could forge messages, unless someone captured the message. So the only person who can forge messages after the conversation is the other participant. Since he could already forge messages, that measure does not increase deniability in normal circumstances.

It is also unclear what "after a conversation" means. When does a conversation end? In any case, the technical paper doesn't say keys are revealed after a conversation.

It is confusing to write that "However, _during_ a conversation, your correspondent is assured the messages they see are authentic and unmodified."
While it is true, your correspondent obviously does not lose that assurance after a conversation.

"Deniable authentication" is IMO contradictory. A better term might be "private authentication", for example, meaning you privately authenticate to your correspondent. In any case, we shouldn't simply name the property, we should describe what it provides.

-- 
Filipus Klutiero
http://www.philippecloutier.com