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

Cas Cremers <cas.cremers@gmail.com> Thu, 23 January 2020 13:59 UTC

Return-Path: <cas.cremers@gmail.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 2A57D1200C1 for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 05:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 CUe5QBn6qNCc for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 05:59:39 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0255B12009C for <mls@ietf.org>; Thu, 23 Jan 2020 05:59:39 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id j42so3143114wrj.12 for <mls@ietf.org>; Thu, 23 Jan 2020 05:59:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c1KqrqygBYYq7I6eWMDzJSN0BF0jVHJtAPT0qO2pCbw=; b=R8C3VEIuSRFyGt73L7nfxgrIuj/Bbyr2L+EyNUeX10jhGGzwCZgpUZon+bjcBq3j7o dkE2A2RjV6/MJzZx9GWRPStdTcGnlPVTFDQmrmly2BNS6NoFQdioSEEFAAcP55QTyBlE T2ImOztUAbVImhBMPe2HLVPBeO5AvpAIEY3azBbgC0trZZNeJ4jFQzvmPLpQeIF9zXlv AT7R2iVx6PxiVB9BIToNNwBKc59lrMjQLsS1v5IwRLVCYAPoLRPA73qkwq89Vb9IAOLC tJ6SF17S7AiM+1KVcFYCkOVwPX0HIPZttj76/EoRAzxP6THvJHrDfF2cto1IyiHK+L81 umaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c1KqrqygBYYq7I6eWMDzJSN0BF0jVHJtAPT0qO2pCbw=; b=sRC9lb8a0xln8eXTIJy+zOZa51vJS/CGFn7FDZq8AhsI4of9OgWrJUHpEntsWLMdGs qFIGMET984sPGoJ5OvVNb3BpvHdWAugXZzTH7AiDNrxd5C3fiwtK4VwGo3Fglj5NNvvM NliOMlXHE8NLVMlaFAzBx/6vtbSxUYEq2qyJIxJy9SqjxRpFccqTdn5qioDdkqt6sXeY kIicORAGsNSfStV4rLgPvp49iMG2ZgnOl21ye1oWgujjBlZH2Nx9zap3RzxL65fAmZjB WIguixPCCf/iSDN3RRhBlIM4JxlduRtjSkoMI9tpkMSF1CU7gFhUlnwFw3iPqI3lB1A0 nFqA==
X-Gm-Message-State: APjAAAVCRzkp5Ir1DdgA/Omj8YfQM22j0aWqEG+81E1gNtAaGNOUSfh3 yrQrI5vRaw6pTqC8O8zW5cDnDBMk
X-Google-Smtp-Source: APXvYqy9+HP7bpX9q1Z1W7WEzOcjIywVL9r51prwu7aUMct34eob6SjO3UxqhcFtzfhB1k8HLKDcmQ==
X-Received: by 2002:adf:e6c6:: with SMTP id y6mr17533685wrm.284.1579787976939; Thu, 23 Jan 2020 05:59:36 -0800 (PST)
Received: from [134.96.225.154] (mbpc41.cs.uni-saarland.de. [134.96.225.154]) by smtp.gmail.com with ESMTPSA id b17sm3115617wrp.49.2020.01.23.05.59.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jan 2020 05:59:36 -0800 (PST)
To: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>, "jon@callas.org" <jon@callas.org>, "raphael=40wire.com@dmarc.ietf.org" <raphael=40wire.com@dmarc.ietf.org>, "mls@ietf.org" <mls@ietf.org>
References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com>
From: Cas Cremers <cas.cremers@gmail.com>
Autocrypt: addr=cas.cremers@gmail.com; keydata= mQGNBFyjFJQBDADNlXG/t7Nd15sfLSf+jaDMUZJvnz59PW5OYoubAWqqNGQBK6A6ahPb6ebX epYdBp/ilE+n1KP/evaV8dMaktooeptOB7D3neOvRox73o2JEjNTC+8OU90dNmGo9UxAVPS9 HuEuJsmvvssiWg97hZBeaPf2F/Hfg2U+RlAKIpR+c+wdc2lTRMqhQXN8OskzQZzlEP8LrMER 1ZT9q22/bdN7nKnpsXSEB8hj8y1dErZHA3+6m73srG7Q7Muw5Kr6zCF4OTXrXsajHHsEyZFj L7qm9BYyrWQ9yXb0l0vWb+i1tzTEK20NoSJiapk3/0prU54dgK3FqQM8SRm7R1wd5mFGN+4x c8pMd/CvHZfJmN4WT581dxaKFMsTFRXMefMKrzbKTgYLsa6tjpFL/sVf06PSkihk/Tc6qrf0 0nxs6pmGHycfC70zwqqqgFdyYQqTUqMforH5cLpms55O4ONCJ6fk+r0fuQO4qXSRK2z00Rpz mJi0WcKyfiHbB/guH5Rqdc8AEQEAAbQjQ2FzIENyZW1lcnMgPGNhcy5jcmVtZXJzQGdtYWls LmNvbT6JAdQEEwEIAD4WIQRIa4Hi/W0N8sfSgzj/8IKxn6kiTQUCXKMUlgIbAwUJAeEzgAUL CQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRD/8IKxn6kiTZlWDACFkJBQwDlyCwbp8/hoo4MM awQiLC43SZs8YcTYhX11JVBYvFX3JaphqNdzO8rabtEurHY+R3HOXtHOmMrh+dvDqHIt9q9F dW2B0b7Cs2ayvsI/wRjjS6YTMv8ufGDyLc+DvPvabiEMhCHCA1JQ/qBbzIM9D6DqcJqySR1V /nZjWWAgODQ6BN5xaDXZ8IZGv3s0BIvoCV4E0G5oTQY+3I2pxK40A/0yQERkG+P3xYx71QXQ EPQNOTou/JdWtoehpS5WK8z1PEhWTyVfhin0VXr29cCnKi/d7GIVMmniiEBH9R7QqYPqyJEb DvyUifwaS3HkJtjt1zFURBzeHW+usFza+5cN70qeHVyljjeNrMUAFa0aV1MuCDi4NQOMWkYu 3kjNEqELH+YCi16helZLy1X+AgYjiuzy58/O+WqgqOpnOVWTSBy79XX59ca47vS7BBrmGZTr 5ZvVIXGBHFmSHm0Lkn7TOeszR3L+TZUt8vv50M/+7b0mh+jl6J4i4vb1LsS5AY0EXKMUlQEM AMnddlUgDeoW5jU0pmylA2jtexsT/0EiY+Z0h1cBjP4vWcPJua9K/dBJwPujfshRBSYw97+W Z8h9CoFyK8nWVhRLtALwa9PrlpJ0T2PKbspnb1FTu+eTMEM05YxRD5y0eTY7Q/vdauZ/r1x8 CCOimBZ63Djh5xBogXBUUOm+aLArWaL0/Y/3OUdu00ztrL/IRUF3bDvJch58D6vxvw6IDGMG TzUWGcV0WDyYleUZ1qBEYRsa7JTJ71uJLLRc8NRnaEsD2XkHDhcwHoqk+DIwhuWAdo+i0TGJ fmTcqT2U+3X3WCkEh2Oj4PTA1eb1suEDoicueFGm1tcJ5q9dVuY3weZVDycfMmpzHl3bPhP4 EVkfXvOjUgO0E5UnIo24NnmugBBslEW3+DEd38IUZPjmzYFU8v+OMShJ8siVS7+BTL/na3/g lBhrvNjFNG9p5Wxe+572lZuNa+7tphVb+ipnt2h+3RH/I83fekUODm/+CeVhwYMAhKRfLWhi sfpHogOkNQARAQABiQG8BBgBCAAmFiEESGuB4v1tDfLH0oM4//CCsZ+pIk0FAlyjFJUCGwwF CQHhM4AACgkQ//CCsZ+pIk0YGgv/YENZhZTtgBRVP9FeGTnpJ+YHwzfIXXExj/kbV0c/pSdQ j4vhKclmDRd/rX/IpEpvipfPNgJMfAbiq0uPYgmmoIlGecOQAzYWJxsMPNs5Coz0xDU2hRx+ OnY1ueusLvJN/msxxhdT0lnnQiaGKw5dntnu8dUjdG1vvESd2Mg5rmXalo3MfERF465PYz4r ewIyELT8oaCyqldDrNyNxn64fsDqoYx/md8yQQJJl//LHuVXTy7ylN/NiuF9FWO8z19Ttc/E JeHwCASU24+S4o5gj0A2HgUoxNDzhpxtUGfRH3shGnJ1KeqsRtgxwocd6XL8kaXzYmVOgOyW CN6pu6PpISxW82HogdcblVhvudLoZdO5enwHoWwxfqH6lc0O2jZ86eZb8NiFPi5hxXjEzm9d UBBj4bryCnq9z3UtBX+WUW1bkCCjjrtGVI/peZWP3TyNkgZ6Xwt/tj2Vpqf/2ujnDnWPnztB hoF/x6+xCfXBkpKQD8RbIoBO1sJ6VEDwpIks
Message-ID: <eefe9673-37e0-d244-14c5-dd34e4256cf7@gmail.com>
Date: Thu, 23 Jan 2020 14:59:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <2060195243.218290.1579787145340@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/IqwsKCejiiYiT_jP7FD0RUpqmoE>
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 13:59:42 -0000

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, 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
>