Closed beurdouche closed 3 years ago
Among humans, there are afaik no realistic user stories in which deniability actually protects people who lack power because message circumstances are always considered compelling in practice. Yet, there are plentiful user stories in which very powerful people are protected by deniability in combination with their ability to manipulate media, corrupt courts, etc.
I'd thus tentatively conclude that deniability is actually harmful when widely deployed because deniability can only protect powerful people from powerless people, and almost never the reverse. There is a similar argument that deniability enables framing more often than claims of being framed can provide protection.
Also, it appears deniability can always be broken post-compromise because one party could transition their conversation end into a secure enclave, thanks to forward secrecy. In a legal setting, you cannot even protect both side by running both ends in a secure enclave from the beginning.
It's possible deniability serves some use cases among people of approximately equal power. As an example, a family member who engages in a behavior another family member considers distasteful being able to lie to another family member who discovers their messages. It's questionable if such defenses really work much in practice, but they do not appear nearly as unlikely as when the two parties differ in power.
Avoiding signatures has use cases in automated communications, like in extremely low CPU settings, but maybe that's beyond the project scope.
I liken non-repudiation to always being on the record with a reporter. Given these are digital circumstances and UXs typically eliminate the deniability you're likely right that it doesn't provide any additional guarantees in a practical or legal setting.
I'd personally like to see it added if it doesn't remove additional properties in the hopes that legal systems may support arguments of deniability in the future. Practically speaking the strongest argument for making deniability by default would be to reduce the computational requirements as @burdges pointed out above. We're looking at trying to use this protocol with IoT devices, so having that reduction in computational overhead (even if it's minimal) could be helpful in expanding to some very edge IoT use cases.
It's clear deniability only amplifies injustice whenever power imbalances exist:
All legal systems accept circumstantial evidence, meaning deniability could never exclude evidence in court. You could only use deniability to make a counter accusation that evidence was intentionally forged, but courts give little or no weight to such counter accusations. In short, courts would never themselves make deniability arguments broadly accessible. And ditto legislators.
If otoh you hold significant wealth and power already, then you can corrupt judges or more likely sew distrust in the public sphere. These are deniability arguments, but they increases injustice.
In short, deniability amplifies injustice by never supporting weak parties and favoring parties who already wield significant power.
As an amusing aside, there is the CSI effect in which juries came to expect more forensic evidence due to watching the TV show CSI. Could juries come to expect more cryptographic evidence? As a rule, forensics is represented far more accurately in fiction than physics or mathematics or computer science, making this exact scenario unlikely. Yet, if real cryptographic evidence became ubiquitous then yes maybe it would eventually be represented correctly, and then juries might demand it more. Is this possible? Yes maybe, but amusingly it becomes almost impossible if people already use deniable messengers.
With regards to deniability in court systems, I think your points ring true in my anecdotal experience. Given I want to take this back to a broader community and make the case for what you're articulating, are there any examples I can give to support these claims further?
Also, what are the effects deniability provides on privacy preserving system? One of the things that we're looking to do is build a correlation resistant system on top of this to prevent metadata analysis whenever possible. Does the use of non-repudiation by default vs deniability by default reveal additional meta that could be used to adversely correlate a user?
The main reason, I'm asking this is because I understand that a large portion of this group has a strong understanding of the implications of this. I want to be able to use strong logic based arguments if I'm going to bring this to the community I'm working with who has pushed strongly for deniability by default with the option of non-repudiation as an addition.
One of the problems with the term "deniability" (or "repudiation", a term I'm more accustomed to) is that it is often debated without any specific scope. It's fine to hold someone accountable in a context; it's another thing entirely to make that accountability immediately and permanently global. I am fine sending a message to my bank that I can't deny to my bank; I am not necessarily fine with the idea that the bank can show that message to any arbitrary third party that they choose, whenever they choose, under whatever circumstances they choose, without telling me, just because the communication used MLS. They undoubtedly have third-party audit requirements--but I want them to have to ask me to go on the record for auditors, and I want to be able to send an MLS message to them that doesn't give away that freedom until I've formally consented.
The Hyperledger community, and in particular the Aries and Indy projects (which would like to use the MLS standard when it is mature enough) requires repudiation (meaning the ability to deny origin to anybody except the intended recipient of a message) as an option. Their analysis of its importance is here: https://github.com/hyperledger/indy-hipe/blob/master/text/0037-repudiation/README.md. A pithy summary is these two sentences:
If Alice tells a secret to Carol, who should decide whether the secret is reshared--Alice, or Carol? In an SSI paradigm, the proper, desirable default is that a sender of secrets should retain the ability to decide if their secrets are shareable, not give that guarantee away.
I don't disagree with @burdges that deniability can make certain abuses worse--but I do disagree with a premise in some earlier comments, which is that because human power imbalances will inevitably exist, we should build into the MLS architecture a kludge that removes precision and power from the system. That line of thinking would have us eliminate strong encryption, too, since abusive governments are better key management and sophisticated configuration choices than private individuals.
What we should do instead is create technology that's just as easy and safe to use for a peon as for a powerful government or corporation--technology that makes it clear when a message is sent whether it is repudiable, so abusers of power can be held accountable for bad behavior instead of letting them throw up their hands and say, "Sorry, we had to demand that you talk to us on the record, because that's the only thing the technology allows." If all MLS messages are non-repudiable, there is only on-the-record communication, which eliminates whistleblowing and #MeToo reporting.
Hey!
I'm replying into this after some long time; but better now than never.
@burdges , thanks for the comments!
Among humans, there are afaik no realistic user stories in which deniability actually protects people who lack power because message circumstances are always considered compelling in practice. Yet, there are plentiful user stories in which very powerful people are protected by deniability in combination with their ability to manipulate media, corrupt courts, etc.
As real-world examples, there are many actually, as this is the reason why 'off-the-record' is a journalist term, and it has been always used to protect sources. Corrupted people have used deniability from a legal standpoint by using pausible deniability, which is not the same as off-the-record, nor deniability in cryptographic terms.
I agree that deniability have not been used in court case; but many cryptographic properties have not been used as well. It is well know that judges accept plaintext as evidence, without any authentication mechanism related to it. But should we wait until these systems introduce and understand these properties, or protect prior to?
I'd thus tentatively conclude that deniability is actually harmful when widely deployed because deniability can only protect powerful people from powerless people, and almost never the reverse. There is a similar argument that deniability enables framing more often than claims of being framed can provide protection
The same can be said to other properties, as anonymity. The case around deniability is that, in the real world, we have deniability because, unless recorded, we can always deny having said or done something (even if it is an action that is considered malicious). Creating systems that undermine those rights, set up precedences for other rights to be taken away as well as confusing users (I'm sure that many of the users that use messaging applications don't think that the records of their conversations to which they have been authenticated, will last forever and are shocked when those records are used against them on court systems).
Also, it appears deniability can always be broken post-compromise because one party could transition their conversation end into a secure enclave, thanks to forward secrecy. In a legal setting, you cannot even protect both side by running both ends in a secure enclave from the beginning.
That is true for offline deniability; but not for online deniability.
@kdenhartog, thanks for the comments as well:
Also, what are the effects deniability provides on privacy preserving system? One of the things that we're looking to do is build a correlation resistant system on top of this to prevent metadata analysis whenever possible. Does the use of non-repudiation by default vs deniability by default reveal additional meta that could be used to adversely correlate a user?
Metadata, by default, is deniable, as it is not authenticated. This is the misunderstanding around deniability: a protocol is deniable in its authentication if the authenticating parties can authenticate themselves; but there is no proof of this authentication that can be presented to anyone, as anyone could have simulated the authentication. Often metadata is not authenticated, which means that anyone could have created it. If it is authenticated then there is always a correlation between your identity and the data, and, then deniability comes into play: by proving an authentication mechanism with no evidence.
@dhh1128 , thanks for the comments as well!
One of the problems with the term "deniability" (or "repudiation", a term I'm more accustomed to) is that it is often debated without any specific scope. It's fine to hold someone accountable in a context; it's another thing entirely to make that accountability immediately and permanently global. I am fine sending a message to my bank that I can't deny to my bank; I am not necessarily fine with the idea that the bank can show that message to any arbitrary third party that they choose, whenever they choose, under whatever circumstances they choose, without telling me, just because the communication used MLS. They undoubtedly have third-party audit requirements--but I want them to have to ask me to go on the record for auditors, and I want to be able to send an MLS message to them that doesn't give away that freedom until I've formally consented.
This is an amazing definition and what deniability is really about: being able to authenticate; but that authentication cannot be proven by or for anyone else.
The Hyperledger community, and in particular the Aries and Indy projects (which would like to use the MLS standard when it is mature enough) requires repudiation (meaning the ability to deny origin to anybody except the intended recipient of a message) as an option. Their analysis of its importance is here: https://github.com/hyperledger/indy-hipe/blob/master/text/0037-repudiation/README.md. A pithy summary is these two sentences:
I'll for sure check this out.
There are many systems wanting to achieve deniability nowadays: image an abuse report system in which you want to report something but that this report does not have a link to your identity so no one can afterwards blame you. And yet you want that the reportee is assured of your identity but this person cannot prove it to anyone else. This is deniability helping unbalanced situations.
Just adding here as well some of the open issues or sections on the mls documents that refer to deniability:
<!-- OPEN ISSUE: Signatures under the identity keys, while simple, have the side-effect of precluding
deniability. We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii)
some other key obtained through a different manner, such as a pairwise channel that provides deniability
for the message contents. -->
<!-- OPEN ISSUE: This scheme, in which the tree hash covers the parent hash, is designed to allow for
more deniable deployments, since a signature by a member covers only its direct path. The other possible
scheme, in which the parent hash covers the tree hash, provides better group agreement properties,
since a member's signature covers the entire membership of the trees it is in. Further discussion is needed
to determine whether the benefits to deniability justify the harm to group agreement properties, or
whether there are alternative approaches to deniability that could be compatible with the other approach. -->
#### Non-Repudiation vs Deniability
As described in {{client-compromise}}, MLS provides strong authentication within a group, such that a
group member cannot send a message that appears to be from another group member. Additionally,
some services require that a recipient be able to prove to the service provider that a message was sent
by a given client, in order to report abuse. MLS supports both of these use cases. In some deployments,
these services are provided by mechanisms which allow the receiver to prove a message's origin to a third
party (this if often called "non-repudiation"), but it should also be possible to operate MLS in a "deniable"
mode where such proof is not possible. [[OPEN ISSUE: Exactly how to supply this is still a protocol
question.]]
As real-world examples, there are many actually,
I'm listening..
as this is the reason why 'off-the-record' is a journalist term, and it has been always used to protect sources.
This is not an example. Anonymity could prevent a journalist from revealing a source, but deniability cannot help because a journalist can always reveal anything they know. I'd expect the journalist would be believed and the source would face retaliation, unless the source holds enough power to make believing the journalist inconvenient for others.
The same can be said to other properties, as anonymity.
No. Anonymity works because being anonymous avoids involving other power relationships, so anonymity levels the playing field. Almost all cryptographic properties work this way, but employing deniability involves other power relationships and even exacerbates them.
The case around deniability is that, in the real world, we have deniability because, unless recorded, we can always deny having said or done something (even if it is an action that is considered malicious).
We're already exposed to all other power relationships when we attempt to deny. Imagine a corporation doing illegal toxic dumping:
I agree that deniability have not been used in court case; but many cryptographic properties have not been used as well.
We mostly know what happens in both legal courts and the court of public opinion: You could exploit deniability only if you're powerful otherwise. We mostly focus on cryptographic properties that do not require legal tests. ;)
It is well know that judges accept plaintext as evidence, without any authentication mechanism related to it.
There is authentication of a sort being used, like "Another person said the denier said something similar on another occasion" or "The user lacks the knowledge to edit the application's database" or "It's complex to call this powerful entity, cop, etc. a liar so I'll just believe them".
But should we wait until these systems introduce and understand these properties, or protect prior to?
Among the user stories I've seen discussed thus far, cryptographic deniability protects only powerful people.
As for online deniability, it's been years since I looked into Nick's nice papers, so maybe I've forgotten details, but.. I'd expect ring signatures would provide the worst option in practice because they prove that one participant said something, so the powerful participant can always blame the powerless one. It's especially bad for whistleblowers because a document merely existing in the chat incriminates them.
There are related ideas that appear actually useful however:
Imagine a messaging application that employs signatures non-deniably but erases them after verification and whose user interface limits attribution: It provides a shared editable document like a hackmd, so writes anywhere they please, but make conversation possible inserting text like "Speaker: " or whatever. It might encourages editing conversation history into a more concise and useful form too, although not sure exactly how.
A religious parent cannot so easily accept such a document as evidence that their child is gay because the partner could trivially be playing a joke. A court cannot so easily accept this document because both sides could trivially edit one anothers' text and were encouraged to do so. It does not help whistleblowers much however..
I'm listening..
I already told you.
This is not an example. Anonymity could prevent a journalist from revealing a source, but deniability cannot help because a journalist can always reveal anything they know. I'd expect the journalist would be believed and the source would face retaliation, unless the source holds enough power to make believing the journalist inconvenient for others.
No, it can't. Journalists are aware of the identity of the source; and many times are required to know the identity, as to know that the data provided is true. There are many examples of journalists that have historically use off-the-record, that I wont be listing here, as a quick search will do for you.
No. Anonymity works because being anonymous avoids involving other power relationships, so anonymity levels the playing field. Almost all cryptographic properties work this way, but employing deniability involves other power relationships and even exacerbates them.
Not a valid point for me, as the same can be applied to deniability.
We're already exposed to all other power relationships when we attempt to deny. Imagine a corporation doing illegal toxic dumping: We've whistleblower W who exposes this, but later gets exposed herself. W cannot benefit from deniability because her adversary accepts paintext evidence and possesses vast resources. We've an executive E who ordered the dumping too. E benefits from deniability because they possess resources comparable with those prosecuting them, i.e. large skilled legal team, PR experts, political contacts, etc.
With enough resources, anything can be proven in a court and make your case win. If that is your threat model then nothing will work for you. If your threat model is a corrupted legal system like in many countries, then no system will ever work for you as: evidence could be fabricated, judges can be bought, illegal access to systems can be made, fake testimonies can be provided, etc.
My point is that if what you are focusing is a corrupt system where the one with vast resources win, then nothing works.
We mostly know what happens in both legal courts and the court of public opinion: You could exploit deniability only if you're powerful otherwise. We mostly focus on cryptographic properties that do not require legal tests. ;)
This is conflating legal terms with cryptographic ones.
There is authentication of a sort being used, like "Another person said the denier said something similar on another occasion" or "The user lacks the knowledge to edit the application's database" or "It's complex to call this powerful entity, cop, etc. a liar so I'll just believe them".
That is authentication from a legal stand point of view, and I'm talking of authentication as a cryptographic property.
Among the user stories I've seen discussed thus far, cryptographic deniability protects only powerful people.
Which exact real-world stories that have actually happened using deniability as a cryptographic property? Can you please list them?
As for online deniability, it's been years since I looked into Nick's nice papers, so maybe I've forgotten details, but.. I'd expect ring signatures would provide the worst option in practice because they prove that one participant said something, so the powerful participant can always blame the powerless one. It's especially bad for whistleblowers because a document merely existing in the chat incriminates them.
I think you should re-read the papers ;)
I think you are pretty convinced about deniability so I won't be trying to convince you. Further on the issue I will focus on the aspects that pertain MLS, as I don't think a discussion around the legality of deniability pertains here.
I'll quickly address these two point:
Journalists are aware of the identity of the source; and many times are required to know the identity, as to know that the data provided is true.
It depends upon the journalists skills. We've high profile examples that worked without this knowledge. Anonymity can work, but yes anonymity is very hard to use. I do think "hard to use" tools remain a social good. I'm arguing that deniability is not merely hard to use, but heavily limits who uses it, which makes it unlikely to increase justice.
My point is that if what you are focusing is a corrupt system where the one with vast resources win, then nothing works.
I think the correct threat model is "pragmatic judge", or even "slightly corrupt", so just not some some idealized system that'll probably never exist.
In fact, the court of public opinion provides about the best example judge, as it drives our political processes, and it fits this "slightly corrupt" model: Individual have their ideology and prejudices for which they largely reject change, but their views can be shifted by PR campaigns (expensive and corrupt) and sufficiently strong proof explained well (cheap and juste), so the "truth" has some significant advantage.
I'm less worried about judges being outright bought, etc. than about judges simply "taking the easy way out", which covers all the individuals who make up the court of public opinion. In my example, we've judges who accepts plaintext against W just because they want to punish someone and they've more evidence against W than against anyone else, but who simultaneously rejects plaintext evidence against executive E because prosecuting E sounds like too much trouble, risks damaging the economy, etc.
We decided to handle deniability in a separate document since it will be handled via an extension.
Why we do/do not want to achieve it by default and how it is possible to add it in that case.
Sofía noted: "
We are unsure if there is a will of including deniability in this. On some points it states:
""" [[ OPEN ISSUE: Signatures under the identity keys, while simple, have the side-effect of preclude deniability. We may wish to allow other options, such as (ii) a key chained off of the identity key, or (iii) some other key obtained through a different manner, such as a pairwise channel that provides deniability for the message contents.]] """
""" Non-Repudiation and Deniability As described in {{client-compromise}}, MLS provides data origin authentication within a group, such that one group member cannot send a message that appears to be from another group member. Additionally, some services require that a recipient be able to prove to the messaging service that a message was sent by a given Client, in order to report abuse. MLS supports both of these use cases. In some deployments, these services are provided by mechanisms which allow the receiver to prove a message's origin to a third party (this if often called "non-repudiation"), but it should also be possible to operate MLS in a "deniable" mode where such proof is not possible. [[OPEN ISSUE: Exactly how to supply this is still a protocol question.]] """
If this is something that wants to be included, we will be very happy to answer questions. Nevertheless, there is no way, currently, to achieve the same deniability properties OTRv4 has in a group setting."