Re: [MLS] Contribute as OTRv4 to MLS
Ian Goldberg <iang@cs.uwaterloo.ca> Fri, 09 November 2018 03:18 UTC
Return-Path: <iang@cs.uwaterloo.ca>
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 485E01292F1 for <mls@ietfa.amsl.com>; Thu, 8 Nov 2018 19:18:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 5NgAIHqsCII7 for <mls@ietfa.amsl.com>; Thu, 8 Nov 2018 19:18:38 -0800 (PST)
Received: from mail.paip.net (whisk.cs.uwaterloo.ca [198.96.155.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6941277BB for <mls@ietf.org>; Thu, 8 Nov 2018 19:18:38 -0800 (PST)
Received: from brandeis.paip.net (brandeis.paip.net [66.38.236.131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by emu (Postfix) with ESMTPSA id 657775FC0018; Thu, 8 Nov 2018 22:17:41 -0500 (EST)
Received: from iang by yoink with local (Exim 4.82) (envelope-from <iang@cs.uwaterloo.ca>) id 1gKxJa-0007Kk-DH; Thu, 08 Nov 2018 22:18:34 -0500
Date: Thu, 08 Nov 2018 22:18:34 -0500
From: Ian Goldberg <iang@cs.uwaterloo.ca>
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: Richard Barnes <rlb@ipv.sx>, sofia@autonomia.digital, shivankaulsahib@gmail.com, mls@ietf.org, jurre@autonomia.digital, Peter Saint-Andre <stpeter@mozilla.com>
Message-ID: <20181109031834.GT5018@yoink.cs.uwaterloo.ca>
References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> <CAL02cgRNicnDVKGkmmQUth3hcZQNZa1pB=yvpf-iEfPLqVObTw@mail.gmail.com> <CAPsNn2WJPLrDs7aVmCGPP+bs=AcZJOFz0c-7G6X7VMAzSsJzZA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPsNn2WJPLrDs7aVmCGPP+bs=AcZJOFz0c-7G6X7VMAzSsJzZA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsNUqGc_qe68>
Subject: Re: [MLS] Contribute as OTRv4 to MLS
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: Fri, 09 Nov 2018 03:18:40 -0000
On Fri, Nov 09, 2018 at 09:41:34AM +0700, nalini elkins wrote: > > If deniability is something that's important to you, it would be helpful > to think about how you could fit it in as an optional feature. > > Just to comment, there is a potential human rights issue (right to life) > with deniability. Although extremely beneficial in a number of > circumstances, it is my understanding that deniability can also be used by > people such as terrorists to fight lawful subpoenas. > > I wonder if that is of interest to this group. Please correct me if my > understanding is wrong. I very much wish to be wrong. I can't figure out what you mean by that. Deniability (well, one form of it anyway) is the property that the transcript of the protocol messages does not imply the plaintext messages that were exchanged. Another form is that it does not imply the participation of any particular party. (There are other more complex forms involving online informants.) Plaintext logs are deniable in these senses, since anyone could easily forge them to say anything they like. If we're talking subpeonas, note that courts accept plaintext as evidence all the time; the role of a deniable protocol is to prevent the protocol transcript from *mathematically* implying the message contents or participation. (While at the same time the protocol strongly authenticates the participants and the message contents to those *in* the conversation.) -- Ian Goldberg Professor and University Research Chair Cheriton School of Computer Science University of Waterloo
- [MLS] Contribute as OTRv4 to MLS Sofia
- Re: [MLS] Contribute as OTRv4 to MLS Peter Saint-Andre
- Re: [MLS] Contribute as OTRv4 to MLS Richard Barnes
- Re: [MLS] Contribute as OTRv4 to MLS nalini elkins
- Re: [MLS] Contribute as OTRv4 to MLS Ian Goldberg
- Re: [MLS] Contribute as OTRv4 to MLS Raphael Robert
- Re: [MLS] Contribute as OTRv4 to MLS Sofia
- Re: [MLS] Contribute as OTRv4 to MLS Sofia