Re: [MLS] Contribute as OTRv4 to MLS

Sofia <sofia@autonomia.digital> Mon, 14 January 2019 16:46 UTC

Return-Path: <sofia@autonomia.digital>
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 A841B131187 for <mls@ietfa.amsl.com>; Mon, 14 Jan 2019 08:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4bGLr-50RTr0 for <mls@ietfa.amsl.com>; Mon, 14 Jan 2019 08:46:30 -0800 (PST)
Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C93131181 for <mls@ietf.org>; Mon, 14 Jan 2019 08:46:29 -0800 (PST)
Received: (qmail 96618 invoked by uid 0); 14 Jan 2019 16:39:36 -0000
Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 14 Jan 2019 16:39:36 -0000
Date: Mon, 14 Jan 2019 11:46:20 -0500
From: Sofia <sofia@autonomia.digital>
To: Ian Goldberg <iang@cs.uwaterloo.ca>
Cc: nalini elkins <nalini.elkins@e-dco.com>, Richard Barnes <rlb@ipv.sx>, shivankaulsahib@gmail.com, mls@ietf.org, jurre@autonomia.digital, Peter Saint-Andre <stpeter@mozilla.com>
Message-ID: <20190114164619.GD1024@Sofias-MacBook-Pro.local>
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> <20181109031834.GT5018@yoink.cs.uwaterloo.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0IvGJv3f9h+YhkrH"
Content-Disposition: inline
In-Reply-To: <20181109031834.GT5018@yoink.cs.uwaterloo.ca>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ENrYVAk6wc_NYR5wN0tdbnU2vpo>
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: Mon, 14 Jan 2019 16:46:32 -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.)

I completely agree with professor Goldberg on this. The idea of deniability is
to prevent the transcript from implying message contents and participation while
being strongly  assured you are talking to whom you authenticated with during
the conversation. I don't really understand the comment.

Thanks!
--
SofĂ­a Celi (aka cherenkov)
@claucece / @cherenkov_d
Cryptographic research and implementation at CAD: https://autonomia.digital/
EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F