Re: [MLS] Deniability without pairwise channels.

Raphael Robert <raphael@wire.com> Wed, 22 January 2020 20:40 UTC

Return-Path: <raphael@wire.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 1EB0B120832 for <mls@ietfa.amsl.com>; Wed, 22 Jan 2020 12:40:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.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 K-LX1nOjaD-S for <mls@ietfa.amsl.com>; Wed, 22 Jan 2020 12:40:49 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 1919A120821 for <mls@ietf.org>; Wed, 22 Jan 2020 12:40:49 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id cy15so1000086edb.4 for <mls@ietf.org>; Wed, 22 Jan 2020 12:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gbAmetz8fH0yBvI45/FwL12jwdwSPxiWY6kFws/U1bQ=; b=Sh+yBFfX+QDQJ0yBvSyVAD1T0nuCWULiXg3U0BC+tFqnhPBS7c/Dsn5IKoEU1MFm4g Hrsn5AQtmH3JRXdI7yBTKiG6FXVko5Keu2s1uJYhzRcqayBOegscqaTn1sZGNuOFLlZ7 IDbw1P9Yc38U0z1WgzjRT0XA+porHhgQ6/z4+l4ajjLMCJgn/0ywkxcwo/eMbtNOWn4S n2bwZtVN/qRyNPf3oJrSQTqELecR0oAw3T8CtTo/XhZFpVUFGOsPHLOJz8fdiKTXtgUa uz+lBCm2xGZIagbRP9ADnfm2oKaF2qr7J/HLSjcVBUXvQS3Ue+YztBVuilgRpBVWFwnq dWSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gbAmetz8fH0yBvI45/FwL12jwdwSPxiWY6kFws/U1bQ=; b=E89K6rxw5A/28nvUT1xFO6WAvY8MABlLb3wNBeImLyHeYtJaGOdIgf9sEkCYsiRKw6 Uh2bNHw52tbqnbMr4uhoHeROVL8ITUBjz5zCCjxrA4u0CWROEj3wA3j4PGj0eExOe9cf mV95p3OOmiboAAhuX+EO0I15/J7441CtPwx/nRRak7HJxrHlrp291PyAIioFsTdF/CdY ahx1ZvLJ5at6DAFu3giJWe8oUVy835V8yxOqU9wz1b9XDcshaEWHc6YmQlcJ24DK8UMi KME3EEr7V5E3OwWXc3GT/gxM6IzErV/yp+nNAGRKugoAS9hmphZnRp7YWPyXEkIbq4pK IpEQ==
X-Gm-Message-State: APjAAAUNbbLlSH94c+SXjMI+CmwtXMvKXYYUQdmI01OodDhs3YMNUQ1n Npu7zqA8kUHMSexZ1fdtd5nLy25DFvS+2w==
X-Google-Smtp-Source: APXvYqy/s8hEuytdGrw28z9xEcwBsrY2u8tC1RMg64tpU8l78Ueg+GItE2nWG6KbRYqRO6wprXx9QA==
X-Received: by 2002:a17:906:d4a:: with SMTP id r10mr4082552ejh.125.1579725647568; Wed, 22 Jan 2020 12:40:47 -0800 (PST)
Received: from ?IPv6:2a02:8109:9f40:7754:553d:954a:3eff:4157? ([2a02:8109:9f40:7754:553d:954a:3eff:4157]) by smtp.gmail.com with ESMTPSA id o7sm1500784edv.71.2020.01.22.12.40.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 12:40:46 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Raphael Robert <raphael@wire.com>
In-Reply-To: <9CA95CA6-14B2-4DD0-A888-7FFFC42E77AE@callas.org>
Date: Wed, 22 Jan 2020 21:40:44 +0100
Cc: Mathias Hall-Andersen <mathias@hall-andersen.dk>, Messaging Layer Security WG <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DDC1E59-8EB6-4221-8C7B-465E65C46417@wire.com>
References: <42f46da8-aca8-d63c-4672-e06bd84f8e5f@hall-andersen.dk> <C1D0D1E5-C107-487D-B302-63048109492E@wire.com> <9CA95CA6-14B2-4DD0-A888-7FFFC42E77AE@callas.org>
To: Jon Callas <jon@callas.org>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/UyBf4y9TqS5w4FXiO83okHA9DR4>
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: Wed, 22 Jan 2020 20:40:51 -0000


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

Raphael