Subject: Re: [MLS] Deniability without pairwise channels.

From: "[email-masked]" <[email-masked]>
Date: Thu, 23 Jan 2020 13:45:45 +0000 (UTC)

All,
>> On 22 Jan 2020, at 20:59, Jon Callas <[email-masked]>> wrote:>>>>>>>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert <raphael=[email-masked]>> wrote:>>>>>>>> For general context: Deniability is something that is being discussed right now and we should send some update to the list as soon as we have sorted things a bit better.>>>>>>>> Please do. I have some tart opinions about deniability, and don't want to waste anyone's time before we know what we're really talking about.>>>> It's also probably best not to talk about things like courts and so on.>>>> There are a number of reasons, starting with jurisdictional issues. Inevitably, each of us will talk about legal issues through the lens of our own native jurisdiction and that lens is cracked with our own misunderstandings of law and procedure, not to mention that these things do change over time. A procedural stage setting of today may not be the setting of a decade from now.>>>> Lots of protocols talk about "deniability" and it's often a weird concept that is a term of art and doesn't mean at all what a reasonable person might think. I've had some discussions with people about the "deniability" of OTR and others, where it doesn't mean what any non-expert would think it does.>>>> There are other deniability issues that are peculiar. A way that I've characterized this issue is that deniability assumes that your adversary is either stupid or good. By "stupid" I mean that they understand what deniability is, and might not even look for it. (e.g. hidden volumes in Truecrypt). By "good" I mean that you're going to give some mathematical explanation and they'll accept it. If the adversary is smart and evil, deniability can be a weakness, not a strength.>>>> Here's an example, again with Truecrypt hidden volumes. I once talked to some customs officials in a country that's not mine, and I asked them about hidden volumes. They said, "Oh, yeah, we know about hidden volumes and if we see Truecrypt, we *assume* there's a hidden volume. Why would anyone use Truecrypt and not have a hidden volume?" That might not be precisely evil, but it shows a basic issue. True evil would be that after getting to the hidden volume, they ask you to open up the hidden volume in the hidden volume. You reply that there's only one level of hidden volume and they reply (knowing that you're right, but because they're evil), "That's your story. This is open source software. Open up the other hidden volume.">>>> Another form of assumption as either smartness or evil is that if you have a ring signature that could have been made by Alice, Bob, or Charlie, they just assume that Alice made it and let Alice know that's they're working hypothesis since she's their suspect. (I don't want to go too far down this rathole, but it might be the smart way to bet. Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is the only European in that set -- it's a reasonable hypothesis that Alice made it.)>>>> Thus, when we talk about deniability, let's talk about the specific security property and not an aspirational thing like "deniable" that might not work out the way we think. If the property is that a signature could be made by any element of a set, that's a nice property, even if there are externalities that can winnow that set down, even to a single member.>>>>       Jon>>
>I agree with the above. Ideally we would like to combine academic precision with common sense definitions and be clear about ?>the threat model too. I also agree that we should leave aside legal considerations for all the reasons you mentioned and focus on >the social aspect of the facets of deniability.
>We’ll chew through the existing material to see what could make sense in terms of properties and how we could achieve them in >practical terms. Obviously not all aspects of deniability are straight forward in a group messaging protocol, all the more so since >MLS has strong authentication guarantees that 1:1 protocols might not have.
Without getting into any solutions, I just wanted to put forth some common sense requirements.  I hope that I am understanding  how deniability might work.   Please correct me if I have any misconceptions.
Companies doing financial transactions and wishing to use MLS might have a hard time if there were some aspects of deniability.  For example, if you do a stock trade, it is required to be recorded.  If the stock trading company cannot prove that it was indeed you that did the trade, then it becomes quite problematic. 
Also, for example, if you are getting advice from a medical professional and they wish to know that it is indeed you that they are talking to.  This is important for privacy and other issues.  One does not wish to give health information to just anyone.
I believe I had stated in this group before that the "recording" would be done by a completely transparent group member known to all parties.  For example, when you call a business and you receive the message "You are on a recorded line."   There are quite a few use cases for such a scenario in the business and medical worlds. 
I would support a common sense explanation of the various aspects of deniability along with what cryptographic schemes would do and not do, if I am am making any sense!   I would be happy to work in a team dedicated to this effort.
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

---

From: Cas Cremers <[email-masked]>
Date: Thu, 23 Jan 2020 14:59:35 +0100

Hi,

The "recording" / "non-deniable" properties you are suggesting are not
part of the desired properties described in the charter, so I think it
is best to first try to meet the intended MLS goals -- it's complex
enough as it is.

But perhaps more importantly, I think that applications that wish to
explicitly break any deniability properties can easily do so at the
application layer, and this has no impact on the underlying design of
MLS. I don't see why we would need to cater for this at the MLS layer
even if some messaging applications would like that functionality.

For the doctor scenario you mention one would of course aim for
authentication, but that's a different property altogether.

We're aiming for security first, I think.

Best,

Cas

On 1/23/20 2:45 PM, [email-masked] wrote:
> All,
> 
>>> On 22 Jan 2020, at 20:59, Jon Callas <[email-masked]>> wrote:
>>>
>>>
>>>
>>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert
> <raphael=[email-masked]>> wrote:
>>>>>
>>>>> For general context: Deniability is something that is being
> discussed right now and we should send some update to the list as soon
> as we have sorted things a bit better.
>>>>>
>>>
>>> Please do. I have some tart opinions about deniability, and don't
> want to waste anyone's time before we know what we're really talking about.
>>>
>>> It's also probably best not to talk about things like courts and so on.
>>>
>>> There are a number of reasons, starting with jurisdictional issues.
> Inevitably, each of us will talk about legal issues through the lens of
> our own native jurisdiction and that lens is cracked with our own
> misunderstandings of law and procedure, not to mention that these things
> do change over time. A procedural stage setting of today may not be the
> setting of a decade from now.
>>>
>>> Lots of protocols talk about "deniability" and it's often a weird
> concept that is a term of art and doesn't mean at all what a reasonable
> person might think. I've had some discussions with people about the
> "deniability" of OTR and others, where it doesn't mean what any
> non-expert would think it does.
>>>
>>> There are other deniability issues that are peculiar. A way that I've
> characterized this issue is that deniability assumes that your adversary
> is either stupid or good. By "stupid" I mean that they understand what
> deniability is, and might not even look for it. (e.g. hidden volumes in
> Truecrypt). By "good" I mean that you're going to give some mathematical
> explanation and they'll accept it. If the adversary is smart and evil,
> deniability can be a weakness, not a strength.
>>>
>>> Here's an example, again with Truecrypt hidden volumes. I once talked
> to some customs officials in a country that's not mine, and I asked them
> about hidden volumes. They said, "Oh, yeah, we know about hidden volumes
> and if we see Truecrypt, we *assume* there's a hidden volume. Why would
> anyone use Truecrypt and not have a hidden volume?" That might not be
> precisely evil, but it shows a basic issue. True evil would be that
> after getting to the hidden volume, they ask you to open up the hidden
> volume in the hidden volume. You reply that there's only one level of
> hidden volume and they reply (knowing that you're right, but because
> they're evil), "That's your story. This is open source software. Open up
> the other hidden volume."
>>>
>>> Another form of assumption as either smartness or evil is that if you
> have a ring signature that could have been made by Alice, Bob, or
> Charlie, they just assume that Alice made it and let Alice know that's
> they're working hypothesis since she's their suspect. (I don't want to
> go too far down this rathole, but it might be the smart way to bet.
> Suppose the signature was made at 4am Pacific or 12pm GMT and Alice is
> the only European in that set -- it's a reasonable hypothesis that Alice
> made it.)
>>>
>>> Thus, when we talk about deniability, let's talk about the specific
> security property and not an aspirational thing like "deniable" that
> might not work out the way we think. If the property is that a signature
> could be made by any element of a set, that's a nice property, even if
> there are externalities that can winnow that set down, even to a single
> member.
>>>
>>>       Jon
>>>
> 
>>I agree with the above. Ideally we would like to combine academic
> precision with common sense definitions and be clear about ?>the threat
> model too. I also agree that we should leave aside legal considerations
> for all the reasons you mentioned and focus on >the social aspect of the
> facets of deniability.
> 
>>We’ll chew through the existing material to see what could make sense
> in terms of properties and how we could achieve them in >practical
> terms. Obviously not all aspects of deniability are straight forward in
> a group messaging protocol, all the more so since >MLS has strong
> authentication guarantees that 1:1 protocols might not have.
> 
> Without getting into any solutions, I just wanted to put forth some
> common sense requirements.  I hope that I am understanding  how
> deniability might work.   Please correct me if I have any misconceptions.
> 
> Companies doing financial transactions and wishing to use MLS might have
> a hard time if there were some aspects of deniability.  For example, if
> you do a stock trade, it is required to be recorded.  If the stock
> trading company cannot prove that it was indeed you that did the trade,
> then it becomes quite problematic. 
> 
> Also, for example, if you are getting advice from a medical professional
> and they wish to know that it is indeed you that they are talking to. 
> This is important for privacy and other issues.  One does not wish to
> give health information to just anyone.
> 
> I believe I had stated in this group before that the "recording" would
> be done by a completely transparent group member known to all parties. 
> For example, when you call a business and you receive the message "You
> are on a recorded line."   There are quite a few use cases for such a
> scenario in the business and medical worlds. 
> 
> I would support a common sense explanation of the various aspects of
> deniability along with what cryptographic schemes would do and not do,
> if I am am making any sense!   I would be happy to work in a team
> dedicated to this effort.
> 
> Thanks,
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Jan 2020 14:30:10 +0000

> We're aiming for security first, I think.

If we mandate deniability and mandate PFS, then the risk is that the threat
model ends up less applicable.

We can work around the PFS by (in effect) using MLS as a groupwise key
exchange protocol and exporting a longer term key for message encryption,
but if we destroy cryptographic integrity post-facto, as I assume we mean
by deniability, then that makes life increasingly unpleasant for the cases
where people actually want different properties.

In short, preventing various groups making use of MLS is not security first.

Dave.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 23 Jan 2020 14:33:23 +0000 (UTC)

Cas,   

>is best to first try to meet the intended MLS goals -- it's complex

Maybe we have a misunderstanding.  From the charter:

o Message Confidentiality - Messages can only be read by members of the group
o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with
o Membership Authentication - Each participant can verify the set of members in the group

I just want to make sure that a group member cannot say after the fact that they were not a member of the group.   Let's leave the "recording" participant out of the discussion.  It is taken care of by complying with the Authentication statement above.

Nalini

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 23 Jan 2020 15:45:21 +0100

> We can work around the PFS by (in effect) using MLS as a groupwise key exchange protocol and exporting a longer term key for message encryption, but if we destroy cryptographic integrity post-facto, as I assume we mean by deniability, then that makes life increasingly unpleasant for the cases where people actually want different properties.
> 

In general, I don’t see deniability and authentication as such a strong opposition.

But anyway, MLS is currently at a sweet spot in terms of design:
As a default, because we have such a variety of use cases for the protocol, the authentication
service is responsible for the biding between an identity and the signature key which is used
by the protocol to authenticate members whether it is in a deniable way or not.

The authors and collaborators of the working group are gonna carefully document
each security tradeoffs in the architecture document, but ultimately, since each provider
has the ability to tune the exact way to provide and verify these signing keys, I think there
is no concern to have overall. We will remain careful to allow all these use cases...

B.

---

From: Konrad Kohbrok <[email-masked]>
Date: Thu, 23 Jan 2020 15:55:18 +0100

Hi Dave,

I'm not sure, I understand your use-case here.

Regarding FS: Any participant is free to just keep a log of the plaintexts, thus
circumventing any FS guarantee. If you want to log the keys, any party can do
that as well. If I'm not mistaken could also simply opt not to use an RTreeKEM
ciphersuite and never update the recording party's leaf key.

Regarding deniability: Similarly, any member of a group can simply sign their
messages using their static identity key at the application layer. This would
effectively destroy deniability, but it is up to the application to make that
decision.

I guess my point is that destroying deniability (and FS) at the application
layer is easier then getting it if it is not built into the protocol in the
first place.

Cheers,
Konrad

On 23.01.20 15:30, Dave Cridland wrote:
> 
> 
> On Thu, 23 Jan 2020 at 13:59, Cas Cremers <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> We can work around the PFS by (in effect) using MLS as a groupwise key exchange
> protocol and exporting a longer term key for message encryption, but if we
> destroy cryptographic integrity post-facto, as I assume we mean by deniability,
> then that makes life increasingly unpleasant for the cases where people actually
> want different properties.
>

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Jan 2020 15:35:48 +0000

> I'm not sure, I understand your use-case here.
I work for Pando, doing clinical messaging within the NHS in the UK, and
elsewhere. Quite happy for the NHS to read doctors' and nurses' messages
about patients, less happy for us to be exposed or for anyone who picks up
a nurse's phone.

> ciphersuite and never update the recording party's leaf key.
We can't, actually, but as I say we can export a stable key for message
encryption at each epoch so we're covered.

(We cannot keep a log of the plaintexts since that would place persistent
plaintext data on the user devices which would be problematic for us, since
it's patient data).

> effectively destroy deniability, but it is up to the application to make

Yes, that would probably work.

> layer is easier then getting it if it is not built into the protocol in the

Almost certainly; though this is an ever-increasing number of hoops to jump
through. My concern is that baking in a very particular definition of
"security" runs the risk that it either outright prevents the use in some
cases, or simply prices people out of the market in technical knowledge
terms.

I am already going to end up writing much more cryptographic code than I'd
like to use MLS. Writing more doesn't fill me with confidence.

> exchange

---

From: Konrad Kohbrok <[email-masked]>
Date: Thu, 23 Jan 2020 16:47:16 +0100

The record keeping doesn't have to be in the nurse's phone. You can simply mandate that by default a recording service is added to every conversation. That service can run on a well-secured server.

Implementing or even deploying MLS is certainly not going to be a trivial task. However, I would argue that running your own message encryption on top of MLS (which I can't imagine why you would want that, see above) is more hassle than simply signing messages on top of MLS.

Konrad

Am 23. Januar 2020 16:35:48 MEZ schrieb Dave Cridland <[email-masked]>:
>> circumventing any FS guarantee. If you want to log the keys, any
>party can
>> do
>> Regarding deniability: Similarly, any member of a group can simply
>sign
>> their
>> messages using their static identity key at the application layer.
>This
>> would
>> effectively destroy deniability, but it is up to the application to
>make
>> that
>> decision.
>>
>
>> > If we mandate deniability and mandate PFS, then the risk is that
>the
>> threat
>> > protocol and exporting a longer term key for message encryption,
>but if
>> we
>> > then that makes life increasingly unpleasant for the cases where
>people
>> actually
>> > In short, preventing various groups making use of MLS is not
>security
>> first.
>> >
>> > Dave.
>> >

---

From: Raphael Robert <[email-masked]>
Date: Thu, 23 Jan 2020 17:31:28 +0100

It seems there is some confusion around the properties. Deniability has always been considered as an optional property, this is clearly stated in the architecture document:

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

This means that for use cases where deniability is not required or even allowed (perhaps because of compliance rules in certain industries) vendors can simply chose to not use the deniable mode of MLS.

As Konrad mentioned, FS is not optional and at the core of MLS. For use cases where FS is not desired for actual application messages and instead you want a long term symmetric key, MLS can be used to distribute this key securely among members. These use cases would require a (rather thin) layer on top of MLS that handles symmetric encryption/decryption.

Raphael

> On 23 Jan 2020, at 16:47, Konrad Kohbrok <[email-masked]> wrote:
> 
> On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dave,
> 
> I work for Pando, doing clinical messaging within the NHS in the UK, and elsewhere. Quite happy for the NHS to read doctors' and nurses' messages about patients, less happy for us to be exposed or for anyone who picks up a nurse's phone.
>  
> We can't, actually, but as I say we can export a stable key for message encryption at each epoch so we're covered.
> 
> (We cannot keep a log of the plaintexts since that would place persistent plaintext data on the user devices which would be problematic for us, since it's patient data).
>  
> Almost certainly; though this is an ever-increasing number of hoops to jump through. My concern is that baking in a very particular definition of "security" runs the risk that it either outright prevents the use in some cases, or simply prices people out of the market in technical knowledge terms.
> 
> I am already going to end up writing much more cryptographic code than I'd like to use MLS. Writing more doesn't fill me with confidence.
>  
> 
> Cheers,
> Konrad
> 
> > On Thu, 23 Jan 2020 at 13:59, Cas Cremers <[email-masked] <mailto:[email-masked]>
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> > 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: Raphael Robert <[email-masked]>
Date: Thu, 23 Jan 2020 17:50:53 +0100

Just to rule out any misunderstanding: the deniable mode of MLS we are exploring is optional (as per the architecture document).

Furthermore deniability should not invalidate the properties stated in the charter (in particular authentication). Deniable authentication simply means that members fully authenticate to each other within the group, but members cannot deliver a proof of this authentication to third parties outside of the group. Depending on the flavour of deniability this means that a member cannot prove to an outsider whether a specific message was sent in the group (message deniability), or whether a certain member was part of the group (membership deniability), etc…

I hope this clarifies things a bit.

Raphael

> On 23 Jan 2020, at 15:33, [email-masked] wrote:
> 
> 
> 
> Cas,
> 
> On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> >Hi,
> 
> 
> On 1/23/20 2:45 PM, [email-masked] <mailto:[email-masked]> wrote:
> > All,
> > 
> >>> On 22 Jan 2020, at 20:59, Jon Callas <[email-masked] <mailto:[email-masked]>>> wrote:
> >>>
> >>>
> >>>
> > <raphael=[email-masked] <mailto:[email-masked]>>> wrote:
> >>>>>
> >>> There are other deniability issues that are peculiar.. A way that I've

---

From: Nalini J Elkins <[email-masked]>
Date: Thu, 23 Jan 2020 17:19:43 +0000 (UTC)

Raphael,
Sorry for the top post.  On my phone.

Great!
thanks for the clarification.
Nalini 

Sent from Yahoo Mail for iPhone

On Thursday, January 23, 2020, 11:50 AM, Raphael Robert <raphael=[email-masked]> wrote:

Cas,

Nalini