Re: [MLS] Deniability without pairwise channels.
"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Thu, 23 January 2020 13:47 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 77C6B1200DB for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 05:47:50 -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 KObpRvwXlYPz for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 05:47:47 -0800 (PST)
Received: from sonic303-54.consmr.mail.ne1.yahoo.com (sonic303-54.consmr.mail.ne1.yahoo.com [66.163.188.180]) (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 504E81200D6 for <mls@ietf.org>; Thu, 23 Jan 2020 05:47:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1579787266; bh=/PNXgZuYPU/hUpA4KpozJZKboyCWT4uAO/kJfRww0HU=; h=Date:From:To:Subject:References:From:Subject; b=qH+VAI+nUtjMS1GHNd7JqAPv/SzQFMDrhz6PmsYaWMAkj3iPtvLg7VLKITmU73yweOxvie193pebs/UM4Hfm2PQjIqCz3v6fr6p7o2516jhlFo5shhO01q2ULU8CAPUAAoMON0AN4MZbwP2iKl1ORS/tiiLLreNvBisoLhpPArZ/uLgQ3H0n6hjcI9zCJZsmVnGeu1oy6+1S9fipgeKtA1ttTxfmPOXHyfe7CzHMLIMR9hCtQdOgSULWF2mYjrhmPvmEA/T1TWJTX/4M6YeZbkxF4aUDLdpUp1nRO4YOXeh3ezrLfO1S5vSNizT1CfDEHuNeVUXFZAeULNSD3tW7qQ==
X-YMail-OSG: 1MaD2jAVM1nVl.z8DMabPMysU1WNrpZn7MVC0yhTaPIPgmGCFDziCC7jNVRc5cR R5ZQhpKZ4e6W8S4R0zso56S8qfAoFOe0V4S7MfJfdD4eLeg6UBA1LCEmdz94iZGNtfbTU1DTmAjt A6cIbFJDFSGH6bAOO047Ae4pzvdy2FAiJ6TRp65fei8zeeecF9lhh.OJaU.Kuf2FdIj_TFocnATH 6be_1Lga82u6l76Pzj_mBmpdlocYJd8teWmJQkQuKM6_YWmjFWRwvgfrVm9E6WRyP2fRt.Ok7L2T Eolgf6ae9JyotF3QO.cuHnhRQT.q8UAA_eDOq_FpXpC7tZPTQZUffWGn319Hi9J1XreYvYeQeUDU jwDxtkh0Wp03DZT8goUyeetena2NvoVf5CxA0lUQ_2ZzJiEaj0Eu01XnXz0ytIMHlvqj4E9INbIQ GN7V1T.i.WzMzCuLZvWnCJa7NDAzjRnOu7p4MLyx2lvEREnX3NHsBQGkSMxe3ViOc51RBtJq_41z V3gRWXa0oEvQvbwufDTTPl_jhKgH0fr1bHbMi9R2EbjoyFz2KNeU_sMGVsizut9u3cmRE9Bop8vp nwnyX0N7PEofuMwSLL0UTX0eWqwzH_iFH3rkqYHjT6ZfJJZ54UFclA__xguj0Cj0SkXlOWdtRVk0 _AzkEa9iDUNyXfN_WtR6s2VDt1i87gXa2FzF6oPSH0xjnoKLGgGp2tPPLGC8GvrkOX7KnLuq2tun dcMQQC3Hz55XjcbiCVmTvJdjUGhkJJ0vJLiUY.sgsrf4lySApOKYgF9HlbPgZX448y_GvJ9HFQr_ 8X3jaCQ4VX9zzR7mwjo6MTZ3IdZCqY3qJa4oSAXxxhd4jORHK5yqKqS8jGoMb5U7zx2gr.kx0nYr 7Q1z94IvaUYIFV61aLsHxXNBC66rm5lI.bs6AQul_O5jqCTnvIlPhICGVpLg0m3f3SpfMuFhiWIi QwoaRYraxnKNJ7N1GtiotULdGraAGi5BL.f9LzYDZq9FbR76ExWvpWkc2nCyM1KpUi5NFgdcjzff 0kqwLM_RmYMq_KV_RZk3NtVt5IUhM3dZ6f9ufhKC1hmPlxpvCUfIZTXJaj_hvuNwqHqaN2Qw0R6j ZpLLIGw9MXMvkwFR4Fkh3kB9N_9qZc97ZBCTex112Unwy9CcXGiN6odlEhRFbXrNH_6D8LObGvK9 BCwh7Ixm.EcrkelRcMYk4tedCDOGExRiwJZRnUoscOdRyYTw3vFZ1DQgEtDj9xXutrqsoZBh1ASg XkX0Pt8Dwm4Y3kSSd_5z3JBFyTK4sDk1xxNPvylhF8iloVW5Y5r971RHGLWanlrXf.WrxZ8hHUV5 8ogtL0tByjx9zZ0EHlnofk8OxYdtxXP_Nz0_oRd0kqvQtW3Gs1StFIOkB5bYUukLtnkkrHVYtP8o TrhTmUw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Thu, 23 Jan 2020 13:47:46 +0000
Date: Thu, 23 Jan 2020 13:45:45 +0000
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>
Message-ID: <2060195243.218290.1579787145340@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_218289_1905556058.1579787145338"
References: <2060195243.218290.1579787145340.ref@mail.yahoo.com>
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/I3ZrzXoWAS1CdG8I0qqrtk54es0>
Subject: Re: [MLS] Deniability without pairwise channels.
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 13:47:50 -0000
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] Deniability without pairwise channels. Mathias Hall-Andersen
- Re: [MLS] Deniability without pairwise channels. Raphael Robert
- Re: [MLS] Deniability without pairwise channels. Jeff Burdges
- Re: [MLS] Deniability without pairwise channels. Jon Callas
- Re: [MLS] Deniability without pairwise channels. Raphael Robert
- Re: [MLS] Deniability without pairwise channels. nalini.elkins@insidethestack.com
- Re: [MLS] Deniability -> "recording"? Cas Cremers
- Re: [MLS] Deniability -> "recording"? Dave Cridland
- Re: [MLS] Deniability -> "recording"? nalini.elkins@insidethestack.com
- Re: [MLS] Deniability -> "recording"? Benjamin Beurdouche
- Re: [MLS] Deniability -> "recording"? Konrad Kohbrok
- Re: [MLS] Deniability -> "recording"? Dave Cridland
- Re: [MLS] Deniability -> "recording"? Konrad Kohbrok
- Re: [MLS] Deniability -> "recording"? Raphael Robert
- Re: [MLS] Deniability -> "recording"? Nalini J Elkins
- Re: [MLS] Deniability -> "recording"? Raphael Robert
- Re: [MLS] Deniability without pairwise channels. Sofía Celi
- Re: [MLS] Deniability without pairwise channels. Sofía Celi
- Re: [MLS] Deniability without pairwise channels. Natanael