[messaging] Value of deniability

[Sam Lanning]

On 11/12/14 00:38, Eleanor Saitta wrote:
> On 2014.12.10 19.29, Sam Lanning wrote:
> 
>> On 10/12/14 22:41, Eleanor Saitta wrote:
>>> Un-signed and deniable are distinct properties.  I'm definitely
>>> not arguing against unsigned transcripts; making an active effort
>>> to make repudiation difficult is a very different question than
>>> designing for the field utility of deniability.
> 
>> Unfortunately it's not that simple. In most cases with security 
>> protocols, these two are mathematically as useful as each other, 
>> not-deniable (but with authenticity) is as good as signed.
> 
> That's not remotely clear, on two specific levels, one vastly more
> important than the other:
> 
> First, we can talk technically about the integrity and
> linkability-to-identity of a channel separate from that of a specific
> message.  This is where we can talk about specific security goals in
> the cryptographic sense.  I believe that what I stated is true in this
> sense, but only weakly; I'm open to being persuaded here.

The high level concepts in my previous message extend from a single
message to a channel. i.e. the contents of a channel can be provably
from no one, a single person, or one of two people.

> 
> Second, we can talk about deniability as part of the overall
> user-task-completion engineering effort.  Adding deniability as a
> supported invariant of a system and supporting it throughout the
> system lifecycle (including user education, UI design, user task
> structuring, and user security planning) is incredibly expensive for
> little believable gain, vs. merely not supporting the non-repudiation
> of messages.  If you intend to design for a security invariant, you
> must design for it throughout the system, and at this level,
> invariants are neither interchangeable nor cheap.

And yes I see the confusion. Some of us have been talking about
deniability as a property of the protocol, and some of us have been
talking about denibility of the whole system, and arguing for and
against respectively. These are two different things.

I am actually of the opinion that deniability should be implemented up
to, and no further than the protocol. My reasons being as follows:

* If we completely discard deniability, but keep authenticity (which of
course we want), we require signatures of the data in the channel (see
last email). This means that there is cryptographic evidence that each
person did send everything they sent. And it will stand up in a court of
law as strongly as a chain of PGP signed emails.

* We take deniability up to the protocol level. As we have done with
Axolotl and TextSecure. This means that there is no longer PGP-like
strong cryptographic evidence that people have sent what they did.

* we take deniability all the way up through the system to the UI. Now
in all honesty, I'm really not sure exactly what this would entail
(other than your example of having to "end a conversation" in OTR, and I
haven't studied the OTR protocol enough to know why). TextSecure already
supports deniability, and there is no UI indication of this whatsoever.
It is protecting people without the need for cognitive overhead.

Cheers,
Sam.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141211/9d82c456/attachment.sig>