The extended description contains:

So-called "deniability" is not a feature per se, unless authentication is taken for granted, which is clearly not the case here.

Rather than advertising 2 independant items, these could be merged in a "Deniable authentication" item which would contain both sublists.


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.

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.

In that context, I think it might be deserving of being listed as its
own feature.

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.

A related point is that "forward secrecy" is a secondary property of the underlying encryption system. It makes no sense without encryption (i.e. confidentiality).

Personally, I like to introduce these concepts as "forward-secure confidentiality" and "deniable authentication".

X

Hi,

Ximin Luo wrote (28 Oct 2014 01:11:27 GMT) :

With OTR, users get deniability, which is an important feature for
them. It seems to me that most users don't care at all that
deniability is a secondary property of the underlying authentication
system. If we have to make a choice, I'd rather focus on what is
important from the user PoV. It may be that we don't have to make
a choice, see below.

I suspect that with all this info in hand, someone who cares strongly
about this could come up with a phrasing that:

* structurally, focuses on users' needs, and features they can see
* manages to sneak in the correct terminology that Ximin is proposing,
  somehow

Any taker?

Cheers,

Hi Harlan,

I agree it is an important 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.

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.

No, that's not quite right; OTR sends the authentication (MAC) key *in
the clear* so that anyone capturing the traffic on the wire can
subsequently modify transcripts however they like.

That's also what I was saying. It is not encrypted, but it has no effect except in cases where the communication is captured.