Re: [MLS] Deniability -> "recording"?

["[e-mail]" <[e-mail]>]

Cas,   
 On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers <[e-mail]> wrote:  
 
 >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.

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

On 1/23/20 2:45 PM, [e-mail] wrote:
> All,
> 
>>> On 22 Jan 2020, at 20:59, Jon Callas <[e-mail]>> wrote:
>>>
>>>
>>>
>>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert
> <raphael=[e-mail]>> 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
> [phone]
> 
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
> 

_______________________________________________
MLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mls