[messaging] Value of deniability

[Sam Lanning]

On 11/12/14 01:08, Eleanor Saitta wrote:
> 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.

but it may...

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

What is your opinion on forward secrecy. It never has additional UI
hints to the user... The UI for SSL/TLS in browsers for example has not
changed over the course of its adoption.

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

That assumption being that data may be captured at any point.

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

No. But for all intents and purposes, it is technically identical.

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

Is there zero protective value in forward secrecy?

Of course we can always tell people about it but not give any UI
hints... like forward secrecy.

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

There was a deep technical study here: https://eprint.iacr.org/2014/904.pdf

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

Hmm...

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/bf468cbc/attachment.sig>