[messaging] Value of deniability

[Ximin Luo]

On 10/12/14 22:24, Eleanor Saitta wrote:
> On 2014.12.10 16.12, Ximin Luo wrote:
>> There are a bunch of reasons why deniability doesn't "work in the
>> field". Once we neutralise those reasons, it would "work in the
>> field". For example, metadata leaks and bad endpoint security. So
>> blaming "it doesn't work in the field" on deniability itself, is
>> unfair - it's other things that are the real root of the observed
>> problem.
> 
> This amounts to saying that "as soon as we have a magic wand that
> makes computers secure, deniability will be useful".   The reason
> deniability doesn't work is that when the police present a transcript
> in court, they're believed because they're the police.  Not because of
> the signature status or lack thereof of the transcript.  Why do you
> think that having better endpoint security would make deniability more
> effective?  All I hear is a repeated assertion that this is true.
> 

Systems that provide unlinkability would help to prevent those transcripts from being leaked. Better endpoint security would also help. It's a matter of reducing risk - it will always be there, but taking measures to reduce it helps the end result. Not sure how I can explain it in other terms that would be more acceptable to you as a non-assertion...

>> As far as I'm concerned, the issue of deniability is resolved, we
>> don't need to talk about it any more.
> 
> Great, I'm glad to hear that, because it's in direct contradiction
> with everything else that anyone has said on this subject.
> 

To give some more detail, for (n+1)sec the main points of discussion were/are:

- whether the key really needs to be contributive
- whether it's acceptable to indicate "chat initiated" before confirming that everyone is present with a fresh key, or if it's OK to indicated "chat initiated" without confirming it (but confirming it when the first message is received from each)
- how much we can assume the transport to be reliable / well-ordered
- specifics of how to define / achieve consistency, and timing rules
- misc things like freshness and rekeying strategies

*Who* has been saying deniability is costing us? I do remember this point being passed around at last year's CCC, and maybe it was true for previous efforts - but for the efforts over the past year, we haven't really run into this at all.

>> My point in this previous paragraph was that you can't "roll back"
>> the lack of deniability.
> 
> Yes, I know.  My point is that it's not clear that the lack of
> deniability is relevant to the security evaluation of a protocol.
> 
> If it has literally zero cost?  Sure, great, let's have protocol
> deniability[1].  If it has absolutely any cost?  I'd much rather see
> all of that effort go into things that we know actually matter, like
> doing basic requirements evaluations before designing a protocol, as
> it's not clear if was done in the n+1sec case.
> 
> E.
> 
> [1]: The other case of deniability, hidden information repositories
> inside disk or file encryption systems, is in almost all cases a
> direct harm to users.
> 
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

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