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

Alec Muffett <> Tue, 11 May 2021 06:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A00263A0FDC for <>; Mon, 10 May 2021 23:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2h0UJYZob5Fy for <>; Mon, 10 May 2021 23:11:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56DC33A0FD9 for <>; Mon, 10 May 2021 23:11:58 -0700 (PDT)
Received: by with SMTP id h21so10083587qtu.5 for <>; Mon, 10 May 2021 23:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FS8ko8ZsUdHBrDB5fanFJAucbltwRkj0jK09ro7LHEI=; b=jpIXuHKzdvcsRRgJf52zYxHiokX9k4+zJSOEpHYSpuplSJeLTiI8WMSKHbbiw3Okyz bSNQ5m6IeQDfyXHKqA7vsuI8PLFRQR/Cb0LNMbStRV9L7EU65ziigGox5cR1l7pRH8jj a/XmpI920NoVG9jHmHLbHEFFEAOnIXE+X7+qnG1FSq851lsYv2H1CDHEEK23TXGeD0dP dakPwGu3t5BWmQmIwy5JODftncc2Ehrguo5wHFckD4IgeUhLFT+dVc3ifclw17PRXTTL oODiluHopsvf6VjzZ1nbxB3VxKI7OiQFoyrwhQCWUJDYsrE2blBa13rUShjhhjoYDqz0 uRWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FS8ko8ZsUdHBrDB5fanFJAucbltwRkj0jK09ro7LHEI=; b=Sq2rI89wAbEuEfEr7T+8J1S28BPhpiIjz/hfjmfw/X2PlyuWz7GGMYwSgVMg6tRYDn qw4UbyffvDpMIY5FaVV/d2G1b47txnMVFNCauf0nfPXPAlvJq8LfDFy/tzV776Ch+mxg J6JDxJozT3pkN2hg6A/YQnhyQs04Qg2rrgRSm8iI2uI0w61rr07iusH8m6NsEtNrLNo5 9LNt1AZvzpHFeT0tTzH8oK1NAa52/2WqsSEFKhb57jkR2KZcCSFs+AoRLp0voTfNJNIW 3cvbH302y7y4YbDU8lb4z7Bqe5RJmZ+fF/TujmPuD2azea0Nc365H6aA73aE1J1gUxvc d1Bg==
X-Gm-Message-State: AOAM532LGYjMuxkYpztqMhE3qzsKYNTU23uLkgRpSTfE4gIyIjCvEXpr z2MY5bOrrRf/MJBbzQMO2ApC1Vf7wHqzOLURGoknjMwL4493lg==
X-Google-Smtp-Source: ABdhPJy6UdVLNIC5Saq5mhgwnvg70+sCkDloL8dDpjej65pcToRZ9LF3Jk7ZJhkMuSK7wtvjmja7NcG5lS7Veg1YZXU=
X-Received: by 2002:ac8:4d43:: with SMTP id x3mr27209375qtv.326.1620713516280; Mon, 10 May 2021 23:11:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Tue, 11 May 2021 07:11:19 +0100
Message-ID: <>
To: Mallory Knodel <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="0000000000006bb08805c207c596"
Archived-At: <>
Subject: Re: [MLS] secure & end Re: Functional Definition of End-to-End Secure Messaging
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2021 06:12:04 -0000

On Mon, 10 May 2021 at 17:01, Mallory Knodel <> wrote:

> Alec, I thought I'd respond to your points about adversaries and security
> in my draft by picking up on this theme further up in the thread on your
> draft.
Hey Mallory! Thank you!

This highlights a fundamental difference in approach. And there are two
> ways I look at it:
> The first is how tech is defined. Is a technological thing defined by its
> features, or should we describe outputs that can  be achieved by the
> technology we use?
This is also how I am looking at it - to rephrase: your draft pursues
whether something *looks* like E2E, and mine is busy with whether it *swims
and quacks <>* like E2E; and I am
trying to formalise what swimming and quacking entail.

Both are fine. But in draft-knodel-e2ee we take the former approach. And if
> you're trying to define security, or what it means to be secure, in your
> draft then you're clearly taking the latter approach. Again, the former is
> meant to be rather objective, for users to do with it what they will (eg
> here's what it does, determine if this will give you the output/security
> that you want).
There's the rub: just because it has confidential feet and trustworthy
feathers, doesn't make it an E2E duck in the modern era; the folks at GCHQ
love to say stuff like "of course the messages are confidential; people can
have *confidence* in them, we just need to be able to get at them" - and
other games like that (ref:

> The latter approach means you're describing utopia
Ha! I seem to be describing the norm, rather than some utopian ideal - as
suggested by work in progress at:

The definition even fits both Signal *and* PGP-over-Email, which latter
does not suit the modern era but there's nothing to be done about that. The
point of the draft-muffett-e2esm definition is to be precise, not

and maybe that gives developers some ability to navigate towards that
> ideal, which is why its a valuable approach but a different one. Certainly
> harder!
Developers are not my target market; if anything I think that
draft-knodel-e2ee-definition-01 is better for developers, highlighting
abstract concepts like:

*"A system provides message confidentiality if only the sender and intended
> recipient(s) can read the message plaintext" *

...yet leaving open the concepts of "intended recipients" (GCHQ love to
play with this) and "what does 'read' mean?" and "is the writer a reader?"
and "whether the 'intended recipients' *really* need to see each other?"
and "whether an additional intended recipient can be silently added?" and
"do we need to hide the plaintext size? Yes(3) or No(2)?"

There is space for defining principles, and there is also space for fitness
testing.  I am aiming for the latter.

> The second is specifically concerning tech that is built for security
> and/or privacy by design. We don't need to rely on the idea of an adversary
> in order to make, and therefore describe, a technology.
Slightly disagree.  What we need is a threat model, and fortunately one can
be straightforwardly extrapolated from the concept of "end to end". The
concepts of security and privacy are meaningless without a threat model,
and a threat model is informed by understanding the motivations of a threat
actor.... but it appears that you *agree* with me on this, maybe:

> We should be able to define what is a technology (eg secure messaging or
> encryption) without invoking specific threats, and rather using threat
> modeling to trouble our definitions and designs. I would threat models help
> to problematise designs and definitions, rather than explicitly centering
> them in the description
I'm not quite sure of your meaning here, but... direct threat modeling
works for me, including the "meta" threat-modelling:

- there are people who will try to bend this definition for political aims

- there are people who will redefine words in this definition for political

- there are people who will use any crack in this definition, for political

This is why draft-muffett-e2esm attempts to lock down terminology at a
technical (not "intentional") level of "what this means", because such is

Before I close, in general I've been waiting to make a comment about the
> choice to define secure messaging instead of encryption, because I think
> these previous two analyses lay the groundwork for what I'm about to say.
> That is: from a user perspective, having the two terms coexist is the first
> problem. Say there are apps that successfully implement something like
> client-side scanning or traceable messages. Which is that app-- secure
> messaging or encryption? It's not easily discernible for the user. There's
> too much parity between them for any meaningful distinction to be possible
> with basic inference. "Secure messaging" at the moment in the industry is
> simply a descriptive phrase, not a rigorously defined technology and I
> think it should stay that way. OTOH encryption is specific. Encryption
> means something and it needs a rigorous definition in order to not have the
> meaning of e2ee broadened to include things that it really shouldn't
> include. This is the second problem, that the lack of clarity be used as a
> vector for attack on the integrity of an important technology: encryption.
My intent is to rigorously and clearly define end-to-end secure messaging,
and my solution to "E2E brand dilution" has been improved in section 2 of
Draft-01, as a flat statement:

*2. Requirements for an End-to-End Secure Messenger*
*Software which functions as an End-to-End Secure Messenger MUST satisfy
the following principles, and MUST satisfy these principles in respect of
the provided definitions for all forms of communication and data-sharing
that the software offers. The software MAY comprise either a complete
application, or a clearly defined subset of functionality within a larger
application. Any software that does not satisfy these requirements is not
an End- to-End Secure Messenger, and it does not implement End-to-End
Secure Messaging, nor does it implement End-to-End Encrypted Messaging.*

Which I think is clear enough. E2ESM is a superset of E2EM, and I am sure
that over time, Ricochet will not be the only messenger that implements
E2ESM without requiring a central (or, distributed) "provider".  Briar
kinda does, too, and I am not sure about Cwtch yet.

Optimistically, though: all these challenges are addressable.

Perhaps the greatest challenge is obtaining consensus regarding the
importance of "quacking".

    - alec