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

Alec Muffett <> Mon, 10 May 2021 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BAA93A1EF6 for <>; Mon, 10 May 2021 07:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.824
X-Spam-Status: No, score=-0.824 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, URI_DOTEDU=1.273] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3Hv8AVL9c9Io for <>; Mon, 10 May 2021 07:46:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDC5D3A1F72 for <>; Mon, 10 May 2021 07:46:46 -0700 (PDT)
Received: by with SMTP id l129so15518601qke.8 for <>; Mon, 10 May 2021 07:46:46 -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=KiiOa6nd/vOHihbGTf7KNAR9NwoIuL1OPdIFeMTzX7I=; b=UINqCg3C4ywbCix6cjo19Nh9iYlIBnNss211OcKFTemwQeuhfGYHx+Ix2ajQkbkod1 FMQ6NZjMAgjTymHut/lJ2TgL0K5lc3wCeuqtUm+GvT+9rp/wMwbqN6KViPbuLe7l15Yn RkDS1NcUunf7IiI4v1wtlvutZQv5btCjR5XMD38FSwNbKHfFNsLA2REvNoIUCMlsi+U/ 0Muo/EyIvCD8PtrKvg76RN5V8nh/rlRBgKjLVybOZCTYfAG+BFFNqKp1p3c3Y8RF4fq7 5WhV7Y9hRyhCa+DhnPYyl7rByLnOH6Trp0h+06rPGggplFdAgecFUeo/P95PDLBEEnnW GByA==
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=KiiOa6nd/vOHihbGTf7KNAR9NwoIuL1OPdIFeMTzX7I=; b=fTewD0Cx9gnUyw3TAU3tjoltz1/prXAiOlEgAOiBYTwsG07QiRp4hKuzV8+edXPy+P mzDAz95sptHINmT9rhBlVtjiNKQpnHCbXkN1viTnlPxlfzAGQUPSyXAy225NXZKu3otb NSKEFYITr68gBSTqSEfgna6+fk/eoicGX1mp9MKpipgpNA3qRO1OJRST30dpqWb80GUL D6VTen6OIPBXafvZYEHkb33vRdyZa7vAckNmK+I2gOp+QoazXYS0CKFYv6RTZgeaoBGz P0OEke6KQycSu3qtVevcRTp6mkN3kWRuiQI6J4zeyaTiW0zRKEZYB8TQlGPACwFBm4A5 uzRw==
X-Gm-Message-State: AOAM531iCg2M1ix5p6aMg/VT4NMutLIsRhK7EtybwPCR0B1lCCcEBg5N 6VWH719VuiihA9msgoZsBov+0diC1qIa59yc7f01pqGtMTkMGw==
X-Google-Smtp-Source: ABdhPJykNQ1o+W8UU9lL309czlBIZKDoEAV5pbgAt3ZUmSfjPKulmUepDGaLhbeYXXNNef7GApQ1Egasf4T55KjKvvk=
X-Received: by 2002:a05:620a:127b:: with SMTP id b27mr22241046qkl.104.1620658005060; Mon, 10 May 2021 07:46:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Mon, 10 May 2021 15:46:08 +0100
Message-ID: <>
To: Mallory Knodel <>
Cc: Raphael Robert <>, Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000b1bc1805c1fad84b"
Archived-At: <>
Subject: Re: [MLS] 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: Mon, 10 May 2021 14:46:53 -0000

On Mon, 10 May 2021 at 14:45, Mallory Knodel <> wrote:

> We just added a new section to accommodate for this. It's particularly
> important because if you look at the various attempts to modify e2ee such
> that third parties can know things about the messages, there is play with
> the notion of end. Client-side scanning is a real proposal and putting that
> feature within an app would be awful, but better than putting it in the OS,
> for example.
> But we still need to improve this section. I would really love for someone
> to propose some text changes here to make it as strong as it can be.

Hey Mallory!

I would be delighted to help your effort, too - but to do that I would need
to better understand what the intention or threat model is - what it is
meant to be "strong" against?

My work is focused upon building a metric which can be used to measure any
communications service which claims to offer end-to-end security, whether
or not the service uses content encryption or alternately strong direct
peer-to-peer transport encryption. My goal is to hold yardstricks up
against applications and services and provide a "yes/no" regarding whether
the service is end-to-end secure; and also to speak to whether a
proposed government intervention would cause it to no longer be "end-to-end

I've been working on this blindly, but having finally circulated this draft
I am pleased to learn that the concepts line up quite well with a 2011
paper from David Clark & Marjory Blumenthal:

*"The End-to-End Argument and Application Design: The Role of Trust":*

...and also an earlier (and less relevant) work by the same:

*"Rethinking the design of the Internet: The end to end arguments vs. the
brave new world"*

Quoting the former:

*The original paper provides a hint as to the importance of this
distinction. Using a telephone call as an example, it points out that the
ultimate end points are not the computers, but the humans they serve.8 As
an illustration of human-level end-to-end error recovery, one person might
say to another: "[E]xcuse me, someone dropped a glass. Would you please say
that again?"9 The humans are the prime movers in the activity, the ultimate
end points. The computers are just their agents in carrying out this


*There is an explicit assumption in the original paper that the
communications subsystem is unreliable.'3 This assumption is justified
(both then and now) for the reasons listed above. But there is an implicit
assumption that the end node is reliable and trustworthy. The example of
"careful file transfer" in the original paper 4 assumes that the end node
can compute a checksum reliably and perform other actions designed to
compensate for the unreliability of the communications. It also assumes,
implicitly, that the two ends trust each other. *


*The function in question can completely and correctly be implemented only
with the knowledge and help of the application standing at apoint where it
can be trusted to do its job in a reliable and trustworthy fashion. Trust,
in this context, should be determined by the ultimate end points-the
principals that use the application to fulfill their purposes. Because the
locus of trust is naturally at the ends, where the various principals are
found, "trust-to-trust" is preferable to "end-to-end" from the point of
view of the principals, because it more directly invites the important
question of "trusted by whom?" That question, in turn, relates to questions
that implicate application design, notably "who gets to choose which
service is used?" or "which parts of an application are in which service
modules?" Answers to these questions illuminate who controls what aspects
of an application.*

...all of which resonate extraordinarily loudly with the thinking in
my draft. Dan Geer pointed me at them this morning, and I am still inhaling
the papers excitedly.  I am particularly enamoured of the *"trust-to-trust
is preferable to end-to-end"* concept, because it so neatly encapsulates
the issues that I want to communicate and build upon: that each
{participant or end} is a little universe of self-trust, and that the
purpose of *end-to-end secure messaging* is to build a virtual, private,
tamperproof "series of tubes" between them, irrespective of implementation
technology. :-)

In comparison draft-knodel-e2ee-definition - according to the introduction
- "defines end-to-end encryption (E2EE) using three different dimensions
that together comprise a full definition of E2EE, which can be applied in a
variety of contexts", which is a different goal to my "metricate
end-to-end"; I am reading it as a sequence of features, definitions and
user-expectations, but am not yet seeing what is meant to happen when those
expectations are broken, and I don't know if you're interested in seeing
that suggested and/or against whom that sanction will need to stand?

    - Alec