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

"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Thu, 23 January 2020 14:33 UTC

Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A8F12080C for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itXcHTIei9IX for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:33:29 -0800 (PST)
Received: from sonic303-27.consmr.mail.ne1.yahoo.com (sonic303-27.consmr.mail.ne1.yahoo.com [66.163.188.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC156120813 for <mls@ietf.org>; Thu, 23 Jan 2020 06:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579790006; bh=DwH+jlbJaZGIp4SCBqer6D5Mz+rTbi01240Bu/8Cadg=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=KzakiegFM2ZLzL10dwhFKmpht6AuZNU/cYDXyZtrqa711HLtMFZ5lXKyVRaKdufFpi1DZdqI98LVWe6A++WVRe/JECuN4KQNyinwFnYNzDlm8t3sFLBbS74fMkQWUgk/JecqM/yCJM/w3ryt6z5jObxcOfIXJ6jl62XnAFqWh0PTJQ9GVt1srzeU9FGEUl884n4xSn1tFDZIQcUOIWDf66wpcrKrAP9UF0ynxbZSAUZvRccyA2haB4Q0Zn5FKogqB5oECdZ7hQd5cP+EcZmlHrm07AGzRg1E393sUG5cvYJo32HwGN/4b3PxrYfaiPlHaw9WU0a2p+enAtOwIAHzWA==
X-YMail-OSG: Lpn1m9cVM1niIfcE9AZudEAB9SxuU1PCT1yRiHL.f6iLZm77QD0mO06srE.vfY. 1GNBRg4uRn60TBJhoJeWpq8TsFgqcUNvxR8Eh7Mo341ekjnGcciZEP0IZqIwRTikP2P48NoLlJie MdLIObPbg4tdeAOa1vr.JJHz.jj8n7gkIbxGmOsJECF8xC95zDpkFHID.ZFHWzLJWCAw0RE2qt4Z ixHXQ7vMAYAPbUGHNbtaDcC4Sa.mS6R_6NUBhbdsxzySlkb5De2v04bq3BFB.1euz_CsLbDP2NDi Akg3Trc9ZmhlXADggRdjGS4hGOPtj9A0VAIS8b.DoOVNZd5O3nopLkLLnLbV_v4eo3bnajXzwaLe pCw.L03uWC4bujA1WLqDhSv9OJpjRQkS2JwRFuejYhphpLoZgkMSjEjOIa2WGCLT4qvKCdV02tna rN6ZmNAPiTaqZiAXTc9DL1HcJG.To5P4blKYYtFyn8W7BB869Xf9dnvRbDHE8nyytdsF0sR1eo2Y 0OUE59kUso36bJvOhlprJ6Zcl7hko.6ksIenC1xqS3cqv7.cSt4SBx3gVa9SYAxT2XRnyxfCMVBj 0aRYhYdHNMDz4P5sqHzRU20eBCR3Y4xXpXzGvVt56bcLVTZY5aPODvFThIjC4kcaC7kQ4ux_yXuE HAD.0Eflb72aFSRSesBdTYGOpvZDmcNuSkeLSB8edUtBaUzr_HPwvqMgk5fI6fK5tcs31W1jwrp6 hqrwsqne.2gGBHcxVHmY4Tr0ZslYWTjJyK4E3_6NQGmkww8fdN_i1T9MW.RUZIL0s9hSW0QM44gO UG1vsaQw.KCMF5YNlTVhjKiY1ajYTb9EsjxXdJrPviVnSVwlaVw.4p6d653LUucnRCFeELvLIBEQ Cp5gK.9Ly6xams4Syv4RD7STPYXDZ8iuKxx7S5IJ_NSDhveEnlDiBHKVWqHrc9hM5WTJ71Qtpo6t yhPpfb7lYPnkk1raHU3NC2URaeD0MDXAbwmJjCdyOlYdPXOfpOSVuFwdqO8BDORHK4nkkW5.ARIo jE1LXkNS7kT64GB9l_ej0eF_oxAX.x7TscDTX6tnvxe13fhClLB5eqt8Dadqvoegj887TzQF8NhM 707iRF8FKzOPWXIOPUCS2w8WAQqOAIQujU2e3P2wvuWdS_teBgA8oS9Ce4PHJGBQSV6bgmNlsZIc rx46AjF_BUBT7MKvZyCw9pb52Lr7drWTrEJbX4Z1LVQEBX_5NQcrS0OnNlJJ.fKaYCBcZVriMtwY IU3YJX1ygN6coZG1KkJUoUyHzgP3wGCgDbNd.Zn9rPpQ0lMOy7f0xY0JBGIUaWUOYJA9dIdFQfH2 lOesOzGTdpUXvEV4hpO6PHIMGqctvYnGARfTH.76fOpw_pWjmHh6zlb16mIkyK2o1ZnZdrF4wVr7 9J.SCh2Rloqyh50MR
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 14:33:26 +0000
Date: Thu, 23 Jan 2020 14:33:23 +0000 (UTC)
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: "jon@callas.org" <jon@callas.org>, "raphael=40wire.com@dmarc.ietf.org" <raphael=40wire.com@dmarc.ietf.org>, "mls@ietf.org" <mls@ietf.org>, Cas Cremers <cas.cremers@gmail.com>
Message-ID: <2061064987.251760.1579790003975@mail.yahoo.com>
In-Reply-To: <eefe9673-37e0-d244-14c5-dd34e4256cf7@gmail.com>
References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> <eefe9673-37e0-d244-14c5-dd34e4256cf7@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_251759_14686739.1579790003972"
X-Mailer: WebService/1.1.14873 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/_Lqq4lDUc7xNKzVufDGRGGAMm1Q>
Subject: Re: [MLS] Deniability -> "recording"?
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 14:33:31 -0000


Cas,   
 On Thursday, January 23, 2020, 05:59:49 AM PST, Cas Cremers <cas.cremers@gmail.com> 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, nalini.elkins@insidethestack.com wrote:
> All,
> 
>>> On 22 Jan 2020, at 20:59, Jon Callas <jon@callas.org>> wrote:
>>>
>>>
>>>
>>>>> On Jan 22, 2020, at 7:54 AM, Raphael Robert
> <raphael=40wire.com@dmarc.ietf.org>> 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
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
> 

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls