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

Raphael Robert <> Sat, 08 May 2021 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A79B83A171B for <>; Sat, 8 May 2021 06:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eNEpqgmWb5V1 for <>; Sat, 8 May 2021 06:27:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21A903A1731 for <>; Sat, 8 May 2021 06:27:16 -0700 (PDT)
Received: by with SMTP id b17so13521502ede.0 for <>; Sat, 08 May 2021 06:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ALezc2Gj7lTevPwonoRbZUreX76SEs+XA+lInB585Ww=; b=wld+yM5M4ZmcpH36fkCXYL0B76tB72y3A/xm19Ru7bms95wroyg7D6nB16/zEFltZW 5D/UHhk+ZTyoJ07+w/h7FHrSXCufH4F6Cueo1rB2KbiAWr0M7pOG54IrE8ETtIQpPGUJ Rxg72tORQSsldvSbehimwT7UKg09EoB+merwA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ALezc2Gj7lTevPwonoRbZUreX76SEs+XA+lInB585Ww=; b=m8GPMMU27TxAB4bbIWAfGm7l9DhXhEnFTi8Ui5n2jTNkQjihNcC/P0U7DFtecu2oF+ 0dZKhoUbzrEw3L4a9tqmUpn8Yv3/oiJjt8Zyy1aGAgkR34LBi1lPnrycr1QDXEJjE3mA pf0T2QflCkuyROTEfAkEYdJpAXW351lTDmvxp639lpkiKF8DvWWs4Q/XHFDsxJfyAKLs jaV4exlwkiagRMJN6YCUw9JkW6Ey/jLJHTrqzSppesWTCKmWsF4K12A2I9/6UIpxxI9K WMBbsP9U1pyErr9ywurWwtdYDwLkY6czl8EuY+j6pqqqpwSAlqV2OVZsK0tRQ86mJBmv KMig==
X-Gm-Message-State: AOAM5333p6OvIV11GEOKFBVpxad0SNIhhz2wju3eSsKQgg4BHZ1LDKo6 UzohJgjtx55MxF6PwLg44VZnxA==
X-Google-Smtp-Source: ABdhPJx/mBcCHbb0VCr47ktq7MPqWnQSCUiZg7yebwWiBwa2T3hRJZxpIkNckB/SrMj+8Gc86nqVJQ==
X-Received: by 2002:aa7:cf12:: with SMTP id a18mr17947108edy.160.1620480434561; Sat, 08 May 2021 06:27:14 -0700 (PDT)
Received: from ([]) by with ESMTPSA id t14sm5205651ejc.121.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 May 2021 06:27:13 -0700 (PDT)
From: Raphael Robert <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4924649E-4D1E-4D25-B2BF-84E6EF0C20E7"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Sat, 8 May 2021 15:27:12 +0200
In-Reply-To: <>
Cc: Messaging Layer Security WG <>
To: Alec Muffett <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
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 13:27:33 -0000

> I take your point; I did actually consider that for a while - there would be benefits to being better informed about the other "participants" - but eventually I rejected the proposition as being intrusive and impractical to mandate/require, although there's certainly opportunities for some platforms (?) to offer such information if they choose.
> To explain:
> I don't really "introduce different types of participants'', instead I merely "allow" that they exist; it is fine for one participant to be a human being, another to be an autoresponse bot, and the third to be a conversation-archiver.  The important point is that none of them are "invisible" to other participants as would be the case with a "ghost", nor may there be a "ghost outside the machine" accessing content (PCASM) by means of a back door.
> However the participants MUST be able to see each other, and... from that, how far should we go in terms of visibility?  
> Should "Signal" be required to disclose to the other participants in a conversation that I use both my Phone AND ALSO that I use Signal Desktop on two separate devices?
> Should WhatsApp be required to highlight when I am using WhatsAppForWeb in a browser, rather than my primary device?
> I decided that these questions are beyond the scope of defining End-to-End Secure Messaging, not least because they are heavily platform specific - for Signal the entity is represented by a cryptographic key with several devices, whereas WhatsApp uses a on-phone identity and (roughly) all other WhatsAp "clients" call back to the phone for session keys.

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.

> There could be both false positives and false negatives.
> False positive: A system that works in a way that doesn’t contradict the definitions of the draft, but that contradicts the typical end user expectations.
> False negative: A system that contradicts one or more definitions of the draft (most likely because they are too restrictive) but still meets the typical end user expectations.
> False positives are downright dangerous for end users, while false negatives might hinder the adoption of an otherwise great system.
> I look forward to concrete examples, and will work to adapt the specification to fit them where it makes sense.

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. WhatsApp itself refuted the claim that this was a backdoor and so did a number news outlets (e.g. <>). My point here is that the definition of backdoor might still be problematic in more than one way.

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

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

> Another aspect that is at least partially covered in draft-knodel-e2ee-definition-01 is that of authentication. 
> That is an interesting concept: whether the entity can somehow be linked to an external identity namespace; as we see from arguments about Signal's use of "phone numbers" as an identity principal - and that some people detest their doing so - it's not a required feature of End-to-End Secure Messengers, and so will not appear in this specification.
> I think this plays a big role when it comes to “ghost users” and transparency of participants. 
> This is really interesting; I am getting the sense that you are strongly drawn to the notion of "real" or "genuine identity" being part of an end-to-end secure messenger solution. 
> Would that be correct?

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).
As mentioned above, authentication really matters in the context of E2ESM and the maturity of the concepts that are currently implemented in secure messengers is far behind the quality of the actual E2E encryption in itself.

> Lastly I also would like to mention the MLS architecture draft ( <>) that touches on a lot of these subjects.
> Indeed, I think that you and I last met at a MLS shindig hosted at Facebook some years ago :-)

I believe we did! :)
> While its purpose is a different one, it goes strictly beyond the scope of MLS and highlights aspects that are relevant for many secure messaging systems.
> I hope the above makes it a bit more clear what I maybe failed to express earlier.
> It is really interesting, and I am grateful for the pushback and the opportunity / spark to explain. :-)

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


>     - Alec
> <>