Re: [MLS] Functional Definition of End-to-End Secure Messaging

Raphael Robert <ietf@raphaelrobert.com> Fri, 07 May 2021 14:50 UTC

Return-Path: <ietf@raphaelrobert.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 AACBF3A24C2 for <mls@ietfa.amsl.com>; Fri, 7 May 2021 07:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.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 dKtsJDpky9ju for <mls@ietfa.amsl.com>; Fri, 7 May 2021 07:50:38 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 5FE533A24BD for <mls@ietf.org>; Fri, 7 May 2021 07:50:38 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id gx5so14010731ejb.11 for <mls@ietf.org>; Fri, 07 May 2021 07:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f0dmoDtzWNMnKipke9upYYq/XYcSxBjG5dzQrw5UWcc=; b=uUiV3a/loJXXWGHB/gkw42aN3fpkCZo30ElrNAtX9JRiiUNAOMaDT5khBxKstXQYuA oJHfEzPDYi+0y6SUj1gnKt1P7yk+Qnw2JYGguA2q/TEkSWEdTw7t6QONz7ow0gBrQTHL JMg1P0rt6XzQbf6TkiUBIdiOEv4CuJyAH7jX8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=f0dmoDtzWNMnKipke9upYYq/XYcSxBjG5dzQrw5UWcc=; b=XnbDWsWP6htPFXtF63p17TjhaHkkab/iN7A9RKkYMqapTMAfG1kZV08A1vGMtnzltQ GVT4fd9dFWKXq+req5x6q0hefm01Ivm5LW6/TmAZrrhEGrzQ9hWXNemLfwzDiNDJY8U0 AqZ9M/+QukVJ1TDWnzOWRmqMBe8MaxiRShFTJMjA4XlzUcZZ6bN2p2mNSaOqG0Zmr5N7 wg1sXu4SGLhC5eZHJs2tnwXUPWi/UgB+Lkzjg+EPWaozC/uRAFh1SuWnlTzHPgcFicMP Acjfiaiu57mDdbWwpltc685IfLu7vHXVJuzQk/V6iY1NKECtMYwNr7KfiTihliPrq9bh NA4Q==
X-Gm-Message-State: AOAM530/OzMFDfGIOjfNxRqBRwv0CmvmqaMEvreifJ+OoaKtuFr7CR4/ UTY/jDYkiNzjxVVBrpSbT6qHBA==
X-Google-Smtp-Source: ABdhPJw4HWV1cbt9FeuWeA1pM2Ec2bhaSB9LMrXiVTzsVhIqLFYjAfkFWZxb65t6icIaFdkp9Dw0Zw==
X-Received: by 2002:a17:906:1684:: with SMTP id s4mr10289724ejd.506.1620399031444; Fri, 07 May 2021 07:50:31 -0700 (PDT)
Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id d25sm3583349ejd.59.2021.05.07.07.50.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 07:50:30 -0700 (PDT)
From: Raphael Robert <ietf@raphaelrobert.com>
Message-Id: <E418B2DA-D0E3-473A-A8A1-3248766A90DF@raphaelrobert.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F8F9074-CE3A-4438-9F0A-B19DDE4E3F66"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Fri, 7 May 2021 16:50:29 +0200
In-Reply-To: <CAFWeb9Kb4FwzkT0Bj7jhTxnW+i3qTQanu=JRc73=WDK+NR2Jmw@mail.gmail.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
To: Alec Muffett <alec.muffett@gmail.com>
References: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com> <B0A56CC0-7C7C-4343-886A-020D4CCD7BCD@raphaelrobert.com> <CAFWeb9Kb4FwzkT0Bj7jhTxnW+i3qTQanu=JRc73=WDK+NR2Jmw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/8nZTF0IHeM2MsLHEaBMWBYluiX8>
Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging
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, 07 May 2021 14:50:44 -0000


> On 7. May 2021, at 14:13, Alec Muffett <alec.muffett@gmail.com> wrote:
> 
> Hey Raphael!
> 
> Those are great questions, and I have already updated the draft to address the latter one, but will paste the explanation here, too.
> 
> On Fri, 7 May 2021 at 09:40, Raphael Robert <ietf@raphaelrobert.com <mailto:ietf@raphaelrobert.com>> wrote:
> Thanks for sharing!
> You mention the prior art by Knodel et al. at the end and I’m wondering if it wouldn’t be a better starting point for discussion? 
> Especially since it has the advantage of building upon notions that are well-defined and established in the industry.
> 
> I feel that there need to be two separate approaches; draft-knodel-e2ee-definition-00 focuses deeply upon platform "goals" qualitative provision of end-to-end encryption solutions, rather than to specify what is necessary for an end-to-end secure (via client-server-centric encryption, or otherwise) messenger solution to be worthy of the (currently ill-defined, but widely used) terminology.  It describes "scanning" rather what the effects of "scanning" would look like; it describes "not allowing pattern inference" but remains open to someone redefining what "inference" means, as opposed to leveraging "indistinguishability" for a concrete definition. 

I agree that the two drafts a quite different. Yours is much more specific in certain aspects. And this is where it also gets tricky :)
Dave has a good point that it might not be straight forward to have a “one-size-fits-all” model. draft-knodel-e2ee-definition-00 is much broader could certainly be expanded to include more precise definitions to illustrate the more abstract notions. Just having fixed set of precise criteria sounds nice in terms of simplicity but might simply prove to be insufficient to capture all valid use cases.
In either case, having a document that can be used as a checklist to determine with absolute certainty whether a system is end-to-end-encrypted or not sound like a dangerous endeavour. Given the complexity of the subject, the answer cannot always be binary.

When you say “ill-defined, but widely used terminology”, what exactly are you referring to? Statements in the press? What exact problem needs fixing here? Having a bit more context on that would certainly help with the overall assessment. Maybe we are just talking past each other.

> 
> There is a lot of overlap, but in the end https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5 <https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5> leaves the applied definition of E2E-Encryption somewhat open, whereas draft-muffett-end-to-end-secure-messaging-00 is essentially a long and nitpicky way of saying "If you're gonna call something end-to-end secure, here is what 'end' means, and you will need to respect your ends."
> 
> Obviously with enough discussion and rewriting it would be possible to somewhat merge the two documents, but since they take separate routes towards addressing the matter, I am inclined to see both go forward and see how their utility compares.
> 
>  
> I’m also still struggling with your definition of a “backdoor” in 4.4:
> ...
> You previously mentioned that intent is hard to measure and I agree with that. But I’m quite convinced a design or implementation flaw shouldn’t be called a “backdoor” until there is sufficient proof of intent. If you call it a “backdoor” right from the beginning, most people will assume that intent was there.
> This would be very discouraging for everyone who contributes to E2EE protocols, because it introduces the risk of being stigmatised as someone with (criminal) intent just because an honest mistake was made. Long story short, I strongly reject that notion of a “backdoor” for being intimidating.
> 
> 
> I hear that you are worried about pejorative stigma of terminology, so let me share the rationale that I've just added to the draft:
> 
> In software engineering there is a perpetual tension between the concepts of "feature" versus "bug" - and occasionally "misfeature" versus "misbug". These tensions arise from the problem of [DualUse] - that it is not feasible to firmly and completely ascribe "intention" to any hardware or software mechanism.
> The information security community have experienced a historical spectrum of mechanisms which have assisted non-participant access to PCASM. These have variously been named as "export-grade key restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and Meltdown), "law enforcement access fields" (Clipper), and "key escrow" (Crypto Wars).
> All of these terms combine an "access facilitation mechanism" with an "intention or opportunity" - and for all of them an access facilitation mechanism is first REQUIRED.
> An access facilitation mechanism is a "door", and is inherently [DualUse]. Because the goal of E2ESM is to limit access to PCASM exclusively to a defined set of participants, then the intended means of access is clearly the "front door"; and any other access mechanism is a "back door".
> If the term "back door" is considered innately pejorative, alternative, uncertain constructions such as "illegitimate access feature", "potentially intentional data-access weakness", "legally-obligated exceptional access mechanism", or any other phrase, all MUST combine both notions of an access mechanism (e.g. "door") and a definite or suspected intention (e.g. "legal obligation").
> So the phrase "back door" is brief, clear, and widely understood to mean "a secondary means of access". In the above definition we already allow for the term to be prefixed with "intentional" or "unintentional".
> Thus it seems appropriate to use this term in this context, not least because it is also not far removed from the similar and established term "side channel".
>  
> ...and to call out that last point, I find it particularly interesting to compare "back door" to "side channel"; to me, neither are particularly stigmatic until combined with an adjective to describe "intent".
> 
> I have a back door in my house.  It's not inherently evil.

Whoever built the back door to your house hopefully did so with full intent :) This is precisely where I see the problem: doors are mechanisms built with full intent to enter a building/room. If the building/room can also be entered because the walls were not made thick enough (intentionally or unintentionally), we wouldn’t call this a door. So only when there is a strong suspicion of intent (preferably evidence), something should be called a door. I simply cannot convince myself that a door can be something that is built unintentionally. Hence the risk of stigma.
But maybe I just have an unusual understanding of what a door is. I would love to hear other opinions on this.

Raphael

>  
>     - alec
> 
> -- 
> https://alecmuffett.com/about <https://alecmuffett.com/about>
>