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

Alec Muffett <> Sat, 08 May 2021 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDF263A0CD8 for <>; Sat, 8 May 2021 12:27:30 -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 AXM61QSPGJrl for <>; Sat, 8 May 2021 12:27:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C846D3A0CD6 for <>; Sat, 8 May 2021 12:27:25 -0700 (PDT)
Received: by with SMTP id f8so4955672qth.6 for <>; Sat, 08 May 2021 12:27:25 -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=exA95pgFWQUQ1EJPXgAgoZ6bFfQ/leszRSEdi//ZC7s=; b=rUDERKqViMMX4VHdycLHoyZDk3YhiCdDtgh/Yayz19BmLvVEk00ue164jUCKctiSTV GM79GLEPDbxZQD+YkneMJFA/aJsz6UoFf70+KKjkm3hmyCdUAM2Tlj/Y+ewvWUgFpvwu 30R03oxm7/VID873115DCNOGbGmksxeknTLLkjRQBYGiRlTjnVajK1k7GyTXKIKcxJju 4MRqSbKFQQP/fCTPN5C1s+Ys+mj4MqEOwAiuOTxKi5U9dxWbPcjeR9EJxdKvqsrezEPp KS4z0/kmPoEtv6o4wN/BWvb5qCtXeYhIIlJ/r5F4Qj9R/Kenvi31OaXMnEvzsaT1aPOT dz0Q==
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=exA95pgFWQUQ1EJPXgAgoZ6bFfQ/leszRSEdi//ZC7s=; b=F3pjSmWVJtC2gJ86xHysNE7j9NWR9z/gw3/8J2E1tW0q4PAefiPg9AeGvgZNpOXn+d 8Q9pVleMM8EjBTnxSVwOB3MYGd4pe7xcrDFbsrx/Bzo8h+MlT3dj+XTfip+JFA7TXgGD cn+y46JoejsO31qp5043Epwza4rA1omrMcHIpXpP/GJyD2oV4mWALHiYhQuCTA/LVybY qwN0Rs3nkAikO1IEEbeDMOz8RBC+fMwRB+FmLrfYeuF6VH+9pDk94mhlJq6MV0OFAGeo z7fxhHi5nP57J3ziCcyFmMxzZwGNuR9DzMRhHYdY+Vr2a9XBO1fVP7r4EVFWF99jvTHO BlVg==
X-Gm-Message-State: AOAM532WLbE8w8AHhEpOvBCxAwlGbmBaqErHNK0ovzGUjL9CLsnO2z0V RB+l06vhk7pi1ZgIdYFHj+2ztvRfECufbDBhuca0Lw5LunK3AQ==
X-Google-Smtp-Source: ABdhPJy0nn3rcO7F73EwPjrDvB34iR3Zwqs4CbTCjMypUS3B1Irhnln+58y/3e9frnJK1xMSCM4suLdpoHeMBZHaSXc=
X-Received: by 2002:ac8:72d8:: with SMTP id o24mr5607853qtp.321.1620502043933; Sat, 08 May 2021 12:27:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Alec Muffett <>
Date: Sat, 8 May 2021 20:26:47 +0100
Message-ID: <>
To: Raphael Robert <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000afc01a05c1d6881a"
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: Sat, 08 May 2021 19:27:31 -0000

On Sat, 8 May 2021 at 14:27, Raphael Robert <> wrote:

> Whether users should really see a notification whenever someone adds a new
> device to their account is indeed a matter of debate. If cryptographic
> assurances exist that adding a new device could only have been done by
> possessing some private key material, I believe this nuance is indeed
> out-of-scope for your draft.

Exactly.  I believe that the feature *is* however necessary for
participants to maintain integrity, because there is little benefit in
requiring group conversations to be closed against "participant injection"
(section 3.4) if the security services of an illiberal state will simply
demand (e.g. a hypothetical) that they be provided "Ghost" access via
WhatsAppForWeb, i.e. the ghost is injected into a participant instead of a
conversation.  This is why section 3.5 exists.


Again, the absence of examples doesn’t validate the claim. But I think
> there is a great example nonetheless: the re-encryption vulnerability in
> WhatsApp that was discovered in 2017.
> I think there are lessons to be learned from that:
>  - The vulnerability itself was not something that most people had on
> their radar before it was discovered. It was a "new” kind of vulnerability
> that most people hadn’t thought of. My point here is that you cannot always
> think of all the vulnerabilities in advance and thus produce a false
> negative when benchmarking.
>  - The vulnerability clearly offered a way to access at least one message
> from a WhatsApp user (in its entirety). According to your definition of
> what a backdoor is (in section 4.4 in -01.), this would qualify as a
> backdoor.

The WhatsApp "resend" issue does not qualify as a "backdoor" under this
specification, but you're not the first person to raise that observation.

If we quote Section 4.4:

> Backdoor: A "backdoor" is any intentional or unintentional mechanism, in
respect of a given message and that message's set of participants, where
some PCASM of that message MAY become available to a non- participant
without the intentional action of a participant.

We must also quote Section 4.1:

> Participant: A participant is any entity - human, machine, software bot,
conversation archiver, or other, that is bounded by the extent of that
entity's [TrustedComputingBase].

In the case of the WhatsApp resending "backdoor", each individual message
is legitimately encrypted to key material associated with the participant.
As we all opined at the time, this is a possibly unwise but legitimate
implementational choice:

To leverage this mechanism a malicious actor needs to steal your phone/SIM,
or clone your phone, both of which are initial failures of the Trusted
Compute Base (TCB, Section 4.1) and are outside the scope of this standard.
Otherwise it would also be necessary to accept that the "ability to steal a
Facebook account password" is likewise a backdoor in
FBMSecretConversations; or that "a malicious WhatsApp employee could "nuke"
a user's identity and - in concert with phone-cloning - re-register that
phone number to a new device owned by the malicious employee" is also
somehow a "backdoor".

At some point all "security" comes down to "standing on a bunch of
assumptions", and this standard uses the well-documented concept of a TCB
to express that point.

> WhatsApp itself refuted the claim that this was a backdoor and so did a
> number news outlets (e.g.

I know; I think I was the first to shout about it. Certainly I was the

My point here is that the definition of backdoor might still be problematic
> in more than one way.

I look forward to learning the problems and addressing them.

>  - The vulnerability was in fact a lack of authentication. My point here
> is that authentication really matters for E2ESM, encryption alone is not
> enough.

...and yet not all messengers require PIN-locks, instead trusting integrity
to using phone numbers as the identity principal.  Some E2ESM like Ricochet
(and, I think, Briar?) use bearer-cryptokeys simultaneously as identity
principals and network addresses, so the concept of "identity" is moot.

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?

 - End user expectations were not really met and people were taken by
> surprise. I think was mostly due to the lack of understanding how WhatsApp
> works internally. My point here is that a system should only be called
> E2ESM when there is sufficient understanding of how it works.

...and this standard literally proposes a yardstick to hold up against that

> I’m tempted to make a concrete proposal to maybe quantify this better:
> Whether a system qualifies as E2ESM can only be determined if at least 2
> of the following 3 criteria are met:
>  - The software has extensive documentation about its inner workings that
> cover all aspects that are relevant to security & privacy
>  - The software is open source
>  - The source code has been audited by a sufficiently independent party
> and the unabridged report is publicly available

Those are all political and social requirements, which are nice and I would
welcome more software delivering them, but would exclude (say) WhatsApp
from the list.

I feel that *that* would be controversial.

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

> I feel I should re-iterate that I’m not pushing back on the effort itself,
> I think its really commendable!

Thank you! I hope some value comes out of it, including this

  - Alec