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

Alec Muffett <alec.muffett@gmail.com> Fri, 07 May 2021 12:13 UTC

Return-Path: <alec.muffett@gmail.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 974253A1E6C for <mls@ietfa.amsl.com>; Fri, 7 May 2021 05:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (2048-bit key) header.d=gmail.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 Fq_sf2Ob41jR for <mls@ietfa.amsl.com>; Fri, 7 May 2021 05:13:39 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 662FC3A1E64 for <mls@ietf.org>; Fri, 7 May 2021 05:13:39 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id u7so4633858qvv.12 for <mls@ietf.org>; Fri, 07 May 2021 05:13:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cPhYXj9DSY3xjm8OI0aqKAwgXX1fI/5/k+JBX5HK2Uo=; b=tfaVgmG0D2waAeh/1pa+0DORN8bWg0SKcjl6KYnAZm4WxpuO7mn6cNLmDI+VD683sE RhVSHRnNRPIBYgniObn06opTtzVmM8Uu4gBWKupCwsDahu49vOKmpVm8sXFqUJ1eZJtw zKZK9/XEFhrzEdtN9gcCrymXVPfV9bQYNnJjTjt5Kee6tMtAPxSs4EjX0bZdjq45JOwL FDqrSsyEUKMmMdLszE9T0gbfR6HQa60bT8blb5IX/N5B/9OszsQCELQfA7E59eeLXV89 J3HkbM/6WjvkfKZIOYOYQPg1w7/Dt3dwxE1jrNHsYHKq/jYlJlXhnZmg7YBwUXcqIGl+ GEvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cPhYXj9DSY3xjm8OI0aqKAwgXX1fI/5/k+JBX5HK2Uo=; b=Ugooo27ZrTtLi1QtvxynLLvrM836gTGce36S+eawOC+su1mc1TofsGbRzhgorfGlR6 7RBhoT+JQVaskFvEi0J0p3Tj5ZqSDDZbf3NeqG62f2QHEFWLAgEYLh2fiAeqWsmpT3up 27mDZXmUqjjDDX26MPAbwsbG84m1LzAdJDQjHhaQJR4cXiP0tN3i3yLgMT2BahcLyUvo 9/aivXAWiPVTUqzu5DszLRAzGFd7oaw489Kwul7sKNXp2nVjKqpXAaos+ndsGqVIpUXE qrmXVyoT0DNbmg0vzqHlSGEUa8bvbHRyOkDpXjKCzilC40A0axv5qIqAKl2rC+hOUXOb 9/Mw==
X-Gm-Message-State: AOAM531Koqv8YpF5k9JeRNVVAiYViFhzexwkrF3fgyPm2v90Hqo8Mflu xDAqMhpQtE8BWZ3wOF9HdSYO6m/DzINDQD5R2YA=
X-Google-Smtp-Source: ABdhPJxH/BhbdFdrIHb9S3myA6Z+lFXASoOkEDffedW1VVbt0gfXSjR3UWUsW/fQ/ZtGEQkslctHm/Zv1BFW/IcS/E4=
X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr9396289qve.27.1620389617228; Fri, 07 May 2021 05:13:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com> <B0A56CC0-7C7C-4343-886A-020D4CCD7BCD@raphaelrobert.com>
In-Reply-To: <B0A56CC0-7C7C-4343-886A-020D4CCD7BCD@raphaelrobert.com>
From: Alec Muffett <alec.muffett@gmail.com>
Date: Fri, 7 May 2021 13:13:00 +0100
Message-ID: <CAFWeb9Kb4FwzkT0Bj7jhTxnW+i3qTQanu=JRc73=WDK+NR2Jmw@mail.gmail.com>
To: Raphael Robert <ietf@raphaelrobert.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000885e7305c1bc5bb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/UYeEovy1mccMSUvmaE8vdIHriTI>
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 12:13:45 -0000

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

There is a lot of overlap, but in the end
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.

    - alec

-- 
https://alecmuffett.com/about