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

Alec Muffett <> Mon, 10 May 2021 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E62083A15FA for <>; Sun, 9 May 2021 23:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ubCsfenFl9AA for <>; Sun, 9 May 2021 23:31:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CEC413A15F9 for <>; Sun, 9 May 2021 23:31:09 -0700 (PDT)
Received: by with SMTP id 1so11234474qtb.0 for <>; Sun, 09 May 2021 23:31:09 -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=lEj6z6/S+key911YuyKeKuGgwHIaXKr3jah+FElMdT4=; b=gFmm8mCRxVPlZFhqxYAeeI1+JV+qFIEH7NOvvf2MIm3V4S0fYH7JupcDPC04DaqC2X W6rMHKwnbmIplVRU4A8kOkb6NnXokbyJSlS+/2FbXMtO1iSrY4W2VYIZNrylKL0o6nGu RtMFGb5mRdOdYhw6StEF3QS4JUaTpYfQ2CEmzupl4fVLu/vdrxWvb/KAUQrf/1ITvlLQ RBMxWnWI9QijNs4LQ036IwaFnKbYLxIELzOcE+8eeQNPFDcSuOtVcso4FKhB9QMc4rDO vAjQ2AbfrqPLjWy/NnB87iuP3oGwXHz9iFHFshmChlpnV+IFQDJVeMBfNjZXDl608KGQ wHjA==
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=lEj6z6/S+key911YuyKeKuGgwHIaXKr3jah+FElMdT4=; b=gdivEKZ3M2P/ObCbiFB2kp/CQbclrfAJ/0tSYvLM46vKaA0C05HzCguOLPcnwBpqb0 NKTf2akDSj8jXU2XtGXCD5fAheFz/IZQZSPnBS+ImD7QoYjiUi+t/60Bl+IuGVe8sUM5 RXvao3hm2PaT4hgXgfXk2S4xvlS2KJI+s3dpc1/xjiM8Ds+DUUmVSBROKm60x2gjZKLy +OuVsg2cuGh88WAwlCrZ2RskKigeq8eVFsRtNdlazdwisWMPY7d5kRH1YgNmLrjLl2Q7 qaxc2UR3o2JP5UPAVZ9T3e7DtGIwzXra7SKyciREWMYlZ9jfUuUmQeyUiazi0QnEYZUT uX1Q==
X-Gm-Message-State: AOAM530HJOhKcV6dhfk5YdV41kp8VEm+HaP0CGpKkf/Dqj44xVp2ccx7 Ir5SawJ0HX5pd3u2rF1ZL658klyasOxDvayXwrMmsoDehv7iJA==
X-Google-Smtp-Source: ABdhPJyBYBH6PzqLp+PmP/pUcx8K8y6FW8RrU702Yxp1E6oYUTKyh8G1zDhbUI78JijtXUfMsp4pu/mkfJmJYL4xijE=
X-Received: by 2002:ac8:574e:: with SMTP id 14mr11969621qtx.191.1620628268013; Sun, 09 May 2021 23:31:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Mon, 10 May 2021 07:30:31 +0100
Message-ID: <>
To: Raphael Robert <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="0000000000003a5d6d05c1f3ec0b"
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 06:31:15 -0000

On Sun, 9 May 2021 at 18:58, Raphael Robert <> wrote:

> Yeah, that’s not how I remember it. I’m pretty sure the gist of it was
> that the vendor (or an actor controlling the vendor’s infrastructure) could
> convince WA clients to re-encrypt messages to a different cryptographic
> identity. No SIM-card cloning was required.

Mm; there's a very simple proof of my point: in order to add a new device
and to steal these messages, it is first necessary for the malicious actor
to successfully impersonate a new user device, in order to subvert the
trust that WhatsApp has in the integrity of the user.

To perform this subversion requires SIM-cloning, some form of
phone-jacking, or - in the very simplest circumstance, as happened to one
of my family last week - socially engineering the user to forward the
confirmatory SMS/nonce for new device setup, *to* the malicious actor.

The proof is: this is an abnormal activity. It mostly does not happen,
otherwise far more WhatsApp account theft would occur, enabled by malicious
actors simply connecting a new device and saying "Hey, I am Raphael Robert,
please send me anything addressed to him."

*This* is the concept of a Trusted Compute Base.

We should all be deeply worried that the integrity of Signal, WhatsApp,
etc, all rely upon confirmatory SMSes, but that's outside the scope of this

In short: the matter of "identity" is not obligated to extend beyond the
> consistent and defined concept of an "end" / participant.  As such, it
> falls out of scope.
> That said, I am wondering whether it would be useful to add a wishlist of
> RFC2119 "optional" features, like optional PIN-lockdown for identity, where
> the platform would benefit from it. Maybe this could be one such?
> Agreed, I really wouldn’t consider anything beyond the cryptographic
> identity of an endpoint. Anything else is vendor-specific as you say.


> If rubber-stamping some of FB’s poorer decisions with that draft is a
> desired goal, it changes the optics quite a bit.
> draft-knodel-e2ee-definition-01 has a much higher degree of independence.

That's a tragic strawman; to repeat, the goal is to provide a metric for
judging the "minimally viable product behaviour" for something to be worthy
of being called "end-to-end secure"; it's also short, and measurable
against an implementation.

I was more thinking about the authentication on a cryptographic level
>> between “ends”. The user-level identifier is a whole other dimension (and
>> probably out-of-scope).
> So, notification regarding surprise key changes, that sort of thing,
> perhaps as an addition to Section 3.2?
> It really falls in under “authentication” in
> general. draft-knodel-e2ee-definition-01 has the nice concept of encrypted
> channels (although it contradicts the MLS notion of groups a bit).
> It should be clear to the user at the time of encryption who the
> participants are

For me, that's Sections 3.1 and 3.2.

> and there should be a way to verify the participants and their
> cryptographic identity.

Yes, but "verify them against... what?" [explanation follows below, after

> I know this pretty much excludes iMessage. But if we want a definition of
> E2ESM that covers iMessage,

Rubber-stamping some of Apple's decisions? [joke]

> we need to drop authentication completely and that’s definitely weak sauce.

The word "authentication" is only meaningful within two - what shall we
call them, "frames"?

1/ that the "participant" is-or-is-not part of the conversation; but that's
the very *definition* of an end-to-end-secure conversation: that "the only
people who can read are participants, and participants are those who can
read", and it is the trusted-compute-base of each participant-entity which
defines their participation

2/ that the "participant" somehow relates to some external identity
framework, for instance a PKI or a Driving License Number.

...however I suspect that you may mean:

3/ that the "participant" is fully in control of their devices and
endpoints, and that one of them has not been subverted or inserted by a
malicious actor; but this (again) eventually requires the E2ESM client to
perform a security audit of the device that it's hosted on, etc.  This one
is hard, and possibly illiberal/unwise.

I would like to check please whether I am correctly reflecting your wants
for authentication? 1, 2, 3, or other?

    - Alec