[messaging] Value of deniability

[Eleanor Saitta]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2014.12.10 19.58, Sam Lanning wrote:
> 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.

No, because message capture by an adversary does not necessarily occur
in the context of the channel, depending on the system and message
capture mode.

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

Talking about things only at the protocol level without incorporating
that concept into whole-system-design is generally an indicator of
massive failures in system design.  I would worry significantly about
this decision.

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

This makes assumptions about the level at which data is captured.

> And it will stand up in a court of law as strongly as a chain of
> PGP signed emails.

We have no evidence that supports this assertion.

> * 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 have no evidence that asserts that the "strong" nature of this
evidence is meaningful.

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

There is zero protective value here.  Protection would imply that
users would be aware of the invariant and take it into account in
their operational planning.  This never happens, and can never happen
if they're not told about it.  I would strongly question, even if we
had specific evidence that demonstrated any legal utility, whether
deniability was an appropriate invariant to try to convey to users
given the incredibly narrow circumstances of its conceptual utility.
Simplicity is incredibly important in the design of systems intended
to be used in adversarial circumstances, and new invariants are rarely
free.  How much work has been done to test and ensure that deniability
is maintained in Axolotl?

The arguments being made here make it clear that no whole-system
design input is happening in these systems, a fact which I find
distressing.

E.

- -- 
Ideas are my favorite toys.
-----BEGIN PGP SIGNATURE-----

iF4EAREIAAYFAlSI7p0ACgkQQwkE2RkM0wp4cQD+JtxD9bnOTaZgfMiiPSvqCu5X
wiv7BF6Q1KcpiIlKEbUA/AmnK7/a55sm3UUlu6AWVpqJb9WKUiLIiHaO+Empy7nF
=DqMC
-----END PGP SIGNATURE-----