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

Alec Muffett <> Fri, 07 May 2021 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C5773A2877 for <>; Fri, 7 May 2021 09:23:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BlDLemXSArho for <>; Fri, 7 May 2021 09:23:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB1D13A2872 for <>; Fri, 7 May 2021 09:23:36 -0700 (PDT)
Received: by with SMTP id i17so9003342qki.3 for <>; Fri, 07 May 2021 09:23:36 -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=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=YYCA9+LSuCY8d4tlQRm/LoUU/InQK1jZowNGeAVVb9+Z2G3t2H/PJaxtOq5GjHIMKn SLxo7EtlZH8Kvg2CGlOhyREfDMtiPdAl2j53w40510xps1C+zSh6nBQCtr1V7VMycbmq LSzfzVRXMvQYrpg7tKRCPuuD8CaMVODSKqx50LNLdu0ozih1tC1QXhQAlVtz5q/UJFu6 /Xjbv6aGlV2R8XQAj2ZAjkFVricvktgJP5SkSTwrtWSYDea2y+sGGMHE+CzjfGVb4Mfv VEoGrVeLfqaMqyDvGoXHAkcDT0EpeH307GyDC/mbcCX6W7kyyLNWeacvuMKDyxol2cHU S4zw==
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=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=O9pk3sT6rMuriNFkjviKg4i1NOBZgM0VXgkB6A62S3ORDMhRhf+rNAfyLxmKG4ieIj FvZP7iqwQOX/ZVvstz6trwUEhbv1TsHkN1/5ChvJx+DEoi6mTKzoHbx0fJTYdrfGq+9D 1/b7+SIx6gk9bcd+J6dChnQeM90BBTtQeMb6S0ws27hIv8BjCeUuxJ5wRgYG6jBdI/2M FkraCjwPWwU4jjpbrgrMiXKHEtYJhT3OzkJLzWm86iN9PiErXjS/W4wbB46GXKjel+IQ 0Gzw3iQi/59S4XlK94vwu71pctUrpq87ELX5Xn73zfr7IQlmPPoG01d7ME+TbmvZqXlk hrBw==
X-Gm-Message-State: AOAM5339FxnsqK80D02LjkGAw6hyuSq3L3Ypwk6p4ITjykqSTPh6YgYF WbeV7FfJAfJ7DcT4s3vQQCJiR2s3FCVeYgEg7YYuT7aAI3jASg==
X-Google-Smtp-Source: ABdhPJyboK2Za/zI5LPRFUbuKs02CkHwhSRctpYo1bqbTrDZzy+Id1RAqEHwAdIDOQ15RLy2pwGOiSl/pjEaYyIQ6PI=
X-Received: by 2002:a05:620a:127b:: with SMTP id b27mr10055641qkl.104.1620404614005; Fri, 07 May 2021 09:23:34 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Fri, 7 May 2021 17:22:57 +0100
Message-ID: <>
To: Raphael Robert <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="0000000000006907aa05c1bfd9d6"
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: Fri, 07 May 2021 16:23:44 -0000


All references in the attached, are against:


...which should be constant even if the document is subsequently updated.

On Fri, 7 May 2021 at 15:50, Raphael Robert <> wrote:

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

This is not a one-size-fits-all model of "security".  It's a definition of
end-to-end secure messengers".

It is a formalisation of the following argument:

*1/ in an "end-to-end secure messenger", there are "ends"; this flows from
the expression*

*2/ messages are sent from "ends", to "ends", and a sequence of messages
constitutes a "conversation" (obvious?)*

*3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) to
the current & wholly visible set of conversation "ends" (3.2) ; if it were
not frozen thusly we would lack forward secrecy and simply be reinventing
Yahoo Messenger, which wasn't end-to-end secure, hence we can't be doing

*4/ no "end" may have privileged access to content, (3.1 - participating as
an 'end' does not somehow bestow exceptional access to content, e.g by also
being a database administrator)*

*5/ no "non-end" may have any access to content (3.3.2)*
*6/ it requires the consent ("intentional action") of an existing member,
to add more "ends" to a conversation (3.4) *

*7/ the software should help ends understand where they are logged-in
it.  That's the whole specification, although it's padded with stuff like
"indistinguishability" to disambiguate questions like *"what if we just
leak a *little* bit of the content?"* and *"what about conversation

Everything extrapolates from the term *"end to end secure messenger"*, and
I would be interested to hear examples of purportedly "end-to-end secure
messengers" which don't already meet it.  I would like to know why they do

draft-knodel-e2ee-definition-00 is much broader could certainly be expanded
> to include more precise definitions to illustrate the more abstract
> notions.

And there's the rub; the point of this is to avoid abstract notions,
because we need a concrete definition in order to judge what is meant by
"end to end secure messenger" - not to mention to measure the features
which some states propose be drilled into them.

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

I welcome examples of use-cases where this definition falls short.

Notably this definition *also* works for Ricochet which uses Tor Onions and
point-to-point communication to provide end-to-end security, without even a
hint of content encryption. It turns out that it is not always necessary to
use content encryption (e.g. Signal Protocol) to implement a "closed
distribution list" for a sequence of messages - which is all that "end to
end security" is, in the most fundamental sense.  The technologies have to
adapt in order to address the underlying architecture: client-server,
direct peer-to-peer, mesh, etc.

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.

I would welcome examples of the dangers.

> Given the complexity of the subject, the answer cannot always be binary.

Certainly it cannot *yet* be binary, for want of a metric to measure

> When you say “ill-defined, but widely used terminology”, what exactly are
> you referring to?

"End"; I would be interested to hear what your definition of this term is,
and so we might compare it to Section *4.1* and the explanatory note in
Section *5*,

Statements in the press? What exact problem needs fixing here?

The issue is that "end to end secure messenger" has no definition against
which we can measure the features of a given software solution.  This I-D
offers one.

And then, when the UK Government (or other) propose that "...adding a
'Ghost' will not break end-to-end security", we can precisely measure the
impact of, and rebut, that statement.

Having a bit more context on that would certainly help with the overall
> assessment. Maybe we are just talking past each other.

I hope this helps.

    - alec