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

Raphael Robert <ietf@raphaelrobert.com> Mon, 10 May 2021 19:50 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 35C593A2902 for <mls@ietfa.amsl.com>; Mon, 10 May 2021 12:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, 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: 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 qqPQtLHWQzpy for <mls@ietfa.amsl.com>; Mon, 10 May 2021 12:50:46 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 EDA103A28FD for <mls@ietf.org>; Mon, 10 May 2021 12:50:45 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id f24so26317708ejc.6 for <mls@ietf.org>; Mon, 10 May 2021 12:50:45 -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=rpkxUdb1Eqw/xT5QHaF9IKm6miasqIEdrd8htfcEjoo=; b=Aah1cTi35UqY48IhaCMlqA8oJvK5VcBTLrhmp43mDX0iEpCcKprcMd19InXIOW12zy JFXMz7OyjxPKScUGVOgmBVYmRoB/MtIyr4V7T75lGw4NfsmgbyWMN2Y724bvA42LOhzi htucCySofJkNbwUtfQrf38Eojsw7EnI0GUZk0=
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=rpkxUdb1Eqw/xT5QHaF9IKm6miasqIEdrd8htfcEjoo=; b=muU2ZOMwA/L9mxTp0tDOLBYHQ9jHtDY/fdVdW/pg85ZRNyz4wcfoZlakWC3kJlcPr7 L69atu0sc9rI6vhWLB6s2yR9JPm1XKwbuiL8dudknuYG2s2OJwulq0NoGIE3QumdhszJ RYw05lJLyZDbZ3QBrv5zX76sQZ8IPkKwVXpypQXkSTCusqSypLqnDadiSZ9Ua3jQcBMv ySVAIqLllpLUkr/41kCCbuUF79BUiaYdz66ikY5iVM8U+DUgEKfx01qa/5BNupEKdXbC mCWV1TlhA2DaGVr2yFS5F7sN1lwtaHz7cDDqmi6/yv9J32okOPrBgLALkbsdJNv+NpKd cM6g==
X-Gm-Message-State: AOAM531wBDIVKAzSGMNe39sc3Ho400Z9vmknZsAaIO/yfp1qMgbmnlhC 3/Mrk1ukhvYxmypd83dEY/FJWe7abHnAvnlFE7I=
X-Google-Smtp-Source: ABdhPJyPY33osE4btYA9Z8HGdepwJA+Xh77YXj0zDPlvJrAQ4jw0HvHHR26rLUBAuuxUuAPN6sbKuw==
X-Received: by 2002:a17:906:3385:: with SMTP id v5mr27277406eja.539.1620676243243; Mon, 10 May 2021 12:50:43 -0700 (PDT)
Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id r16sm12408319edq.87.2021.05.10.12.50.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 12:50:42 -0700 (PDT)
From: Raphael Robert <ietf@raphaelrobert.com>
Message-Id: <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_035B5727-9CC8-44BF-A0B0-DE74736965AB"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 10 May 2021 21:50:41 +0200
In-Reply-To: <CAFWeb9JT4Fht=A2BTNEVtgWkfZprpNQUH09DYTzn0=i47oeUiA@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> <FF5A606C-6C51-4670-BB5D-DB495C50A8E3@raphaelrobert.com> <CAFWeb9JT4Fht=A2BTNEVtgWkfZprpNQUH09DYTzn0=i47oeUiA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/1OK5md7TIKbjYI_q3jZK6lEmRb4>
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: Mon, 10 May 2021 19:50:51 -0000


> On 10. May 2021, at 08:30, Alec Muffett <alec.muffett@gmail.com> wrote:
> 
> 
> 
> On Sun, 9 May 2021 at 18:58, Raphael Robert <ietf@raphaelrobert.com <mailto:ietf@raphaelrobert.com>> 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.

I think we need to dial back a bit here. TCB works like a framework, which means it needs a security policy that is clearly defined (Wikipedia article: "the boundaries of the TCB depend closely upon the specifics of how the security policy is fleshed out.”). I don’t see that in the draft yet, except for some provisions in 5.

From your answer it looks like you exclude the vendor as a threat actor, which strikes me as odd since the very essence of E2EE is to protect users against attacks where the vendor is a threat actor.
But I don’t want to jump to conclusions, I’ll wait for a more clearly defined security policy first.

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

If anything, it would be closest to 2. In all usual protocols like PGP, MLS, OTR, Signal, TLS, Wireguard, etc. the endpoints have a public identity key. Whether this key is part of a larger PKI or is otherwise associated with another identifier (e.g. a phone number) is very vendor specific and should be out-of-scope. But the key itself should be part of the system. In more abstract terms, the key is referred to as a “cryptographic identity”. This is the base layer of E2E authentication.
How exactly the key is verified is again vendor specific. The important part is that the key can be verified and that you don’t have to blindly trust the vendor.

Raphael