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

Raphael Robert <ietf@raphaelrobert.com> Sun, 09 May 2021 17:58 UTC

Return-Path: <ietf@raphaelrobert.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200603A184E for <mls@ietfa.amsl.com>; Sun, 9 May 2021 10:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=raphaelrobert.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNa09RrLb_04 for <mls@ietfa.amsl.com>; Sun, 9 May 2021 10:58:51 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49823A184F for <mls@ietf.org>; Sun, 9 May 2021 10:58:50 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id w3so21106032ejc.4 for <mls@ietf.org>; Sun, 09 May 2021 10:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vIpZJKEjnnq411LhFOU9WsModKdZDKHCRPvK5By6TQ0=; b=A9QSuBqI5RWRTOkzwY5N5Y8uHByX2Bn18nqzamx72U5EpmqDPcyetGyYkOYoyDQA12 F+0SlP7EdOpwof+0zYhj/Yzod88S/wgyLMPO95eSnvDWUhYRDjCbkfnBRKcEYUIBvmzk gn+m5rL0MzH2XWpHm7i+9XjE3NLdzPTcvasrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vIpZJKEjnnq411LhFOU9WsModKdZDKHCRPvK5By6TQ0=; b=ui1+Tx5FKT+HYqxIRyQPk/tBX/g16R5aLfJRggYl0GvFTjf6EK7GWLzJ1ZhC9DC0TD Bgpvv57gYdLxpuBHTihnTyXO5GWTg+FnZ0L4JIA+COXZXV68ztDOEMNNIiIIaqKwO9qT spAjvLP1GRi3EVO8Taw68z2C29c5wQmmZdeHA2EbihXYRRcYpMPSngcvSfOSuIkJq8ts 8vTO2F2HI5WQnwnmr3Mw7VvyVpSOB/kervtLuQ/3vUG1pcyo7psBohFH/YwVwfGy2yRm M2SNguSqHFHkGMHhvtfNFL1JuN1NRMIo7Mpu7F8m1bUSqHdwNc+3ulZWQ6E0xWyv6xGs ubnw==
X-Gm-Message-State: AOAM530n7n0yIIZ8J9vRT9PBHqkWqhMOOkvz9ZotZw70U5SGFalx/p7a dyms2pAa9F2gkLhXcL3+FheI/A==
X-Google-Smtp-Source: ABdhPJx+mj2Sf2QTJB2kD6ihXyhZyceY2a7KW7/EJERaIUtlQZ1s6Ubzo8W0D5O+TQl5nh/tytjtFw==
X-Received: by 2002:a17:906:6854:: with SMTP id a20mr21167136ejs.329.1620583128270; Sun, 09 May 2021 10:58:48 -0700 (PDT)
Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id g9sm7262182ejo.8.2021.05.09.10.58.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 May 2021 10:58:47 -0700 (PDT)
From: Raphael Robert <ietf@raphaelrobert.com>
Message-Id: <FF5A606C-6C51-4670-BB5D-DB495C50A8E3@raphaelrobert.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_97C908FE-CF47-4716-9C78-079B77DD1141"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Sun, 9 May 2021 19:58:45 +0200
In-Reply-To: <CAFWeb9K69e+MArYhir-A7docnsTNFZd4vmHovGrDvsBDq0hSRw@mail.gmail.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
To: Alec Muffett <alec.muffett@gmail.com>
References: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com> <B0A56CC0-7C7C-4343-886A-020D4CCD7BCD@raphaelrobert.com> <CAFWeb9Kb4FwzkT0Bj7jhTxnW+i3qTQanu=JRc73=WDK+NR2Jmw@mail.gmail.com> <E418B2DA-D0E3-473A-A8A1-3248766A90DF@raphaelrobert.com> <CAFWeb9LgU+eC0FVndeY-6Kf=NNUf4Lmdhuy2nKXwyK9gDE8UHg@mail.gmail.com> <C64A0465-28E7-4FFE-834A-B1EB50343574@raphaelrobert.com> <CAFWeb9+gD6=QLJ3oXw_mwk_7x8StJ-3MA25fHGHLWjpAR0z-Kw@mail.gmail.com> <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> <CAFWeb9K69e+MArYhir-A7docnsTNFZd4vmHovGrDvsBDq0hSRw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/5p0xd6C1ni9KfLf1FJ9clSsxIfA>
Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 May 2021 17:58:56 -0000

> 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: https://technosociology.org/?page_id=1687 <https://technosociology.org/?page_id=1687>
> 
> 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. https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages <https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages>).
> 
> I know; I think I was the first to shout about it. Certainly I was the rudest: https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-1791158247 <https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-1791158247> (first paragraph) 

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.
I’m absolutely not calling this a backdoor, but it was a way for the vendor to stealthy trigger re-encryption and thus potentially get access to message content. There’s a good chance that falls under your new definition of a backdoor.
I find the section 4.2 & 4.5 in draft-knodel-e2ee-definition-01 less controversial in that respect and they are probably sharp enough to serve as a yardstick.

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

Agreed, I really wouldn’t consider anything beyond the cryptographic identity of an endpoint. Anything else is vendor-specific as you say.

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

Oh well, I see that differently. 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.

> 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 and there should be a way to verify the participants and their cryptographic identity. I know this pretty much excludes iMessage. But if we want a definition of E2ESM that covers iMessage, we need to drop authentication completely and that’s definitely weak sauce.

Raphael