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

Nalini J Elkins <nalini_elkins@insidethestack.com> Thu, 23 January 2020 17:19 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 013C312084C for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 09:19:59 -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=ham 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 51K64EbDzt7n for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 09:19:55 -0800 (PST)
Received: from sonic305-27.consmr.mail.ne1.yahoo.com (sonic305-27.consmr.mail.ne1.yahoo.com [66.163.185.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 B38A1120145 for <mls@ietf.org>; Thu, 23 Jan 2020 09:19:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579799993; bh=r9Xwp8oijNnDDmeW8L3jDzbVgdPzXJBEkymhzp3HLLA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=AqGtD0asmsdpuTdmCKmieLUbBo01LWCw+b3GkywArQXJPhDFuzcUgsgaT77yrtbeCOo+dtWGg6EgpdLqFk7MgX+A6UkSm5I/eUt28wTwqS0EnpfU/jjNPl392vXS55dowTxTT5Y1FopRSjdWfqfaFrdDXpEUzoFS30k5M47nBIqp7liDmUMxcv1VCZLkZoP4NIFSY/F9Q/QGfqlLldFdQroOEngv9TrLFUbZlckBVgJVcU8vM8vEXE1OuVNKbDiJOiYHiI6ss+Em0jQ6tVenc3OQR5jLi3Mh6+EBMPr0k9VWcxlfRb+T2egX30IjNlgO61NX0Wo4RYF1pfOhB/NTfQ==
X-YMail-OSG: IRW_.rcVM1k3v3HJBvpXlYGFN2ck.7oiCF8zDtdwmQ.lD9jY_rxj46BkrWEEPZL lN8ynOsSiyDkUyhDRqRHLmZxO9tVPW7VAAMx2Hpo4TP77EUnlVtmp99XXX35kdhC4aWjWIO7sUSB 1ewxkdhqQ2RbNYzLV9ZDbeiYVCBnaQM_TArMrB5AxK6CzI6lIoCyu8UZFxQAYuYDaQ7fGrFX0w7n JFK3JG0WEBS9ZS3xRrc8uttQJP7qVc7Ss1iaSgRKom.HqSJsrrRVJAaCZilwPM3nMMcmMcpodMh. 28ko7lLLlSKIrRtNxPcHbgIS3i0Y2getEJ7r7piun2lUs9m0GSvS8n8BjTETjs1IvyoprUpk6M5y 1AT4okWn420vbI8Yj8_fGt6gRyUxnqiVSE3qlgvZTXAyBhjzLcNI7Vy.VDf9kMyRQGVExGyl4IG1 JgacM.BmnwDKnBWRzLLdVoVYsN.e91.APJ3fbFQn4M.TJmtT6viIVhwae9Ob4j9pQmwNdNu2Zozc oiN1s5Oyozhy8_Id3ZlIuOzLApYspDAeqcwFwWrdpEKLuYvpVD9IEhcA7mM9HCX8y26rtY7cnWfU PwRsdOBjF_LhqXypvNbuA7GrfytPX_oqYC703G_FeoricaFRdbrfbw0K4kwf3wVqx0sRFofseMRE LS3f7xfS7TioGHQHpatdsHWXmrCCRu5N5M2wB4Oq35aDVRAphdg6_mv5JAAIIUsxJyrtj3o2XRa4 6yZYSDnrpdNKWPrc5xEoNqwaqD3iQAwj.A2dwge.UlpMbsudRbzzXgUuodIKv4p_uNY4Kx1Mx8wK eesfzbEKNH6i4sBNomjOTHtS2PaZ8bcgmYYF4KyHRBQasS0_7378elzP7uz4gpNAmP.wx.eg3dTG iIVL35iEw9JO8xcKpf6m.WrSSW2u8XS_C.JoG1Z9TZLgqRQMGs_mhkCl7DsslpAY7UmUNVE84KA5 3DpCnWYPPRErlcMNjmy9eHDAEDxbB__ekaT2.IJvqaguVjZFi3frhkvJkoEnOirJgiPmk2.f3SsW Ov7xkHnzvDwcCRo7uzRIAcnaQZcXhH5fgS0ewE.hvTAJbHSgVLpPBIxO4lwDDePxt6celp38YfsG quYh_CeqXXcColzCPFUbsZH9Wda4Qf5So8UP3gRHlZ.RW.F6p7gp8o6C2tfKRhQ55sPuLfgqtNco sQFVMqWA6ODQwmX16j0XQBqcUpLDhL96ozm1.ePSrnUj9Wjg3NMa_DNiXKyYm2v30y8aLkq563Mu dL3SbdfL_8ZGustM0zGLNwHrJDqDWZ3GDzqnHV46Kq9J_oS.rB4Y88trVMLPs42a7xDayz43T6Ze O_GszAnazegUr.bAK4hQRd1JhvVLqFq_oINndnaGo3NvfVPQgPsjl9H_lsaJl4mm5oWpc4Mm1eL_ UGv3DOn48R7VcUVgAktb_Y8ZctVUu_h3Br5ODLrl8OPYQYXmFOTwh29Cqr.4cIXCEeMtoV9zYEQ- -
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 17:19:53 +0000
Date: Thu, 23 Jan 2020 17:19:43 +0000 (UTC)
From: Nalini J Elkins <nalini_elkins@insidethestack.com>
To: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>, <nalini.elkins@insidethestack.com>
Cc: "mls@ietf.org" <mls@ietf.org>, Cas Cremers <cas.cremers@gmail.com>, "jon@callas.org" <jon@callas.org>
Message-ID: <903411086.321286.1579799983593@mail.yahoo.com>
In-Reply-To: <3E30B070-68DB-4A56-A02C-E450B2033F54@wire.com>
References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> <eefe9673-37e0-d244-14c5-dd34e4256cf7@gmail.com> <2061064987.251760.1579790003975@mail.yahoo.com> <3E30B070-68DB-4A56-A02C-E450B2033F54@wire.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_321285_1946005536.1579799983590"
X-Mailer: WebService/1.1.14873 YahooMailIosMobile Yahoo%20Mail/48275 CFNetwork/1121.2.2 Darwin/19.2.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Lym6aj62ilsEe5Laj1EfKUf_W70>
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 17:19:59 -0000

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=40wire.com@dmarc.ietf.org> wrote:

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, nalini.elkins@insidethestack.com wrote:


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.orghttps://www.ietf.org/mailman/listinfo/mls
> 

_______________________________________________
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