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