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

Alec Muffett <alec.muffett@gmail.com> Mon, 10 May 2021 07:15 UTC

Return-Path: <alec.muffett@gmail.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 5A1053A09FE for <mls@ietfa.amsl.com>; Mon, 10 May 2021 00:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 (2048-bit key) header.d=gmail.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 iDU7Q-xV5FXI for <mls@ietfa.amsl.com>; Mon, 10 May 2021 00:15:10 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 15AAA3A09FA for <mls@ietf.org>; Mon, 10 May 2021 00:15:09 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id o27so14443788qkj.9 for <mls@ietf.org>; Mon, 10 May 2021 00:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vBYoc8urDTmAK8Qnda8J9rti5lEUH3pOebwxlwa48s4=; b=OknEo1JBsOh8q0LPZ/qQQUaOCU8lLlbJk8sy399h84n2172eyJf8W0d0Q0DiiRu9Dj z8najuqccvMQxf2j2+BEQ0xBjm8zgBUCqiQ7QqvyZ1VmBH8waiWpegCoQJf7XS6+EJNI nh6Sfm+xUJ5p1daGwS8TttQE7YlV5/88EZPGAYMU9cvOxcMi2eP1BWVjO34TodLuiXT9 hgFpJyyI2ViV0k5Jtxc8KzEpqX9zNaSwQ4u8s+vuqoie43GnEX72AghcYmnMk4ygEddE T71XXAxZzMp6sxVqFJRBOjRJvJu5YeRapSwDj+nwh1rb9ATKk1nC3ryMmjNIez/6d+su IqDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vBYoc8urDTmAK8Qnda8J9rti5lEUH3pOebwxlwa48s4=; b=F/CX7ewOc/OJW7auiVj1DW9s0S4VcvycwRKTEuf/RN5vc8tt29OINrlC0qyrrffsJQ nJGkiIeSNcNuFtoYzNVGXRgIGOlthWzpZ6p+Z/I4ub7n6go2K8u/z5glfVrF2Y2moRNS MBl9oq05TWorWjcPJ5dljLqZJ9iZU2//rFZvjx0Qd6QcXGWomtHMyj+GSzYW2LiUh9iP ouBllIyOMxhwNox7AlHH8VHnPZpAa55N5OewJl+yRKnYTO+YkFKDjNcrYoaGShKlq9b4 OpFxL5UCqwO7xwK2SIg0Ih7bZfHzu0O20HPr5lHSshGW18/V8tDSZJ49TqIcOWKj9syh MmTQ==
X-Gm-Message-State: AOAM5312ITbRNWqljdcebv1ftXv1F7dbsM2sOMAwgN0sWCyE4l30da+E qSkcQCgjbZHF5+UQWMtjZLTv1oTNmQYE1P4vl+M=
X-Google-Smtp-Source: ABdhPJzlnbnmuO7NkGZ75AR35QlBqSGvgHgJ1XFmfKHj/2dCJ0OqMhB2gF4XDtoxYlpBEr00U5n/B1EmJWkEqnuDl44=
X-Received: by 2002:a37:9c84:: with SMTP id f126mr21142146qke.240.1620630908012; Mon, 10 May 2021 00:15:08 -0700 (PDT)
MIME-Version: 1.0
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> <937f9db9-d0e2-390e-0ef8-8dfa73e993b0@riseup.net>
In-Reply-To: <937f9db9-d0e2-390e-0ef8-8dfa73e993b0@riseup.net>
From: Alec Muffett <alec.muffett@gmail.com>
Date: Mon, 10 May 2021 08:14:31 +0100
Message-ID: <CAFWeb9K+oB_b=xy3DvdGueA2zCD_Pjqkvq6efZg_XNgTBDLwqg@mail.gmail.com>
To: =?UTF-8?Q?Sof=C3=ADa_Celi?= <cherenkov@riseup.net>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000958d9305c1f489ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/_yK-usubHeT05JJAZPxGTPrOIQc>
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 07:15:15 -0000

Hi Sofía!

On Mon, 10 May 2021 at 00:41, Sofía Celi <cherenkov@riseup.net> wrote:

>
> These are really interesting points. I see four points:
>
> * Future or past recipients of a conversation: it could be that a
> conversation is read prior to the intended recipient, or after the
> intended recipient. This is somewhat not cover in every day
> applications, as someone else can get access to a device and read the
> messages intended for a recipient. In those terms, I think this is
> described as 'secure' for the network (and the intended recipient is the
> device, then); but if a device is compromised, then the contents could
> be potentially read by someone else.


Exactly.  This is the concept of the Trusted Computing Base, in a nutshell:
https://en.wikipedia.org/wiki/Trusted_computing_base




> A point to include here then is the
> idea of 'disappearing messages', as a property for trying to avoid this.
>

They are very useful - I am a strong convert to them, although they are not
obligatory for an end-to-end secure messaging network.



> But if a message is read and disappeared prior to the actual "recipient"
> reading it, then the purpose is also lost.


Yes; or alternatively if they exist until "N" hours or days after being
read on any given device, there are other models where their purpose is
also lost.

On that basis, it's up to the user to make wise choices and use of the
features that exist *beyond* basic end-to-end security.


* Messages read by something that is not a "human": this could be a bot
> that is part of a conversation (but should it be?, if so, it should be
> disclosed to the sender-s-, and potentially properly "authenticated") or
> malware in the device itself.
>

If a "Bot" should be disclosed to a sender, should it also be disclosed
that the user is using an assistive spellchecker app?

Or an assistive keyboard app which may exfiltrate content to Chinese state
authorities?

Example of this latter debate:
https://www.reddit.com/r/privacytoolsIO/comments/kzpxwt/opinions_on_naomi_wu_signal_ime_vulnerability/

Hence why I believe that it is not tenable to pursue disclosures of
anything beyond "these are the participants within this conversation, and
the rest of the universe is outside".

Or perhaps those "assistive apps" exist as backdoors, in which case:

* Messages read by a backdoor or vulnerability: I think that if an
> application has a backdoor (with the whole purpose of having it there to
> read the contents) then it is not end-to-end encrypted.


...does this mean that anyone with a spellchecker (Grammarly:
https://www.silicon.co.uk/security/grammar-extension-data-leak-flaw-228005)
or chinese keyboard, is excluded from what being we would call "end-to-end
secure"?

The only resolution for this that I can see - that is even possible? - is
for the participant to define their "trusted computing base".  Hence this
draft standard.


> If someone or
> something is added to the conversation, then it should be authenticated
> and disclosed.
>

Strongly concur.



> * Multiple devices: this could be better explained by stating that the
> intended recipients could be multiple devices (these all have to be
> authenticated to the conversation).
>

What if one device has several heads, such as "WhatsAppForWeb"?  Should
those be disclosed?

Should a victim of domestic abuse attempting to escape - or: a philanderer
- be "outed" as having a second phone?  As using a secret laptop?

     - alec

-- 
https://alecmuffett.com/about