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

Alec Muffett <alec.muffett@gmail.com> Mon, 10 May 2021 20:49 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 90E3D3A2A8C for <mls@ietfa.amsl.com>; Mon, 10 May 2021 13:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
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: 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 4gAcjBY9Gs6h for <mls@ietfa.amsl.com>; Mon, 10 May 2021 13:49:23 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 374273A2A8A for <mls@ietf.org>; Mon, 10 May 2021 13:49:23 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id h21so9282808qtu.5 for <mls@ietf.org>; Mon, 10 May 2021 13:49:22 -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=p8bwUTCsMGX9r5a+sEOZTBMfARwHMuaWVnBYLAdhWB0=; b=UrFTeh26X9Z62P0a+y3+iie06iPBQvwhpuxtFpjXgYCTSS/T2HWdLMej8kvk6UAszr upcNdaNtQNe4NNnY7UK+MgxJz8JBWaBVP4Lg5blrpTCCqtr7UVksf6uHMUsswXfL4eiL CeOiJA3/q6Bgm/1jmzSEVgprm9lQMezpADxc4F4lrGykCNrGdv+IEB2eOaMhUWs7PGKn WFOia9jXH9dS/AbVnFEWzycKKlgqeAGKMD8xC6QVuioIqfh1F76ZVBGpf9wpvXRCkMFJ Gk5JgXOxB71NW+37KeUC3a6d8U5VRtHO+By3T7GfsKCXYHUHeeJWV+1lbzBgX+1yAiMJ 8AYg==
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=p8bwUTCsMGX9r5a+sEOZTBMfARwHMuaWVnBYLAdhWB0=; b=ce0GIuDwuBfKATy9y5WgtBsMIe5iMPl2J0adf8VzJhrdvtnUxN8sddHLrZMr6UsNHz W97kKtizroHJIOUs5d0KSYmvSbScAUrt+ijeLxswwHozEf7hgmV7AlBOlPvlJ48DJTtK M7h2YTGVK2b7LmZIYQoi7VsaVKUiGENM7HsH59L2EZgFDrzBnZRup9PGTCp/odLAdLqg yIuKdkNhjx2b4HHPeuCbOpzj9Qacshz4/qrD/SEuHydKe9BL4Cd8Jh8cng4J64aZiPFa nFQgXzHvALsAECHNIDdvZSvAmE9IbSWP90T/BpVq7FxFkAM4tVy1qbjd7bzLfNUPiRAN 3zgw==
X-Gm-Message-State: AOAM532qQtcFvUXEBHmbpiY+V64vDiYL3moVt5X2W9Wq0EcvGAab8UzV h6UItyIKTGOIwwNedoGRgVuYAYsMce+jFF8CA2o793FdTRG5gQ==
X-Google-Smtp-Source: ABdhPJxMz9IGiOq4qcU1bfbf4mNcF4g1DDL/kHFg/MQucvO7YzqK0zfkj+4DFTFgODQuc671Utaj5ty1lItNlx06ABc=
X-Received: by 2002:ac8:72d8:: with SMTP id o24mr14966846qtp.321.1620679760914; Mon, 10 May 2021 13:49:20 -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> <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> <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com>
In-Reply-To: <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com>
From: Alec Muffett <alec.muffett@gmail.com>
Date: Mon, 10 May 2021 21:48:44 +0100
Message-ID: <CAFWeb9+A0feFJvTdS4prFxrqj28n-LXWKGtUHwaY+OS-Xcx25A@mail.gmail.com>
To: Raphael Robert <ietf@raphaelrobert.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000071ab5e05c1ffe935"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0Okel1gnQE1ZqXhUZf_N7R2hjj0>
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 20:49:29 -0000

On Mon, 10 May 2021 at 20:50, Raphael Robert <ietf@raphaelrobert.com> wrote:

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

Correct.  It's not possible for an app to tell a user what their security
policy can or should be.

That would be like the tail wagging the dog.

The user has (whether they realise it or not) a security policy and threat
model.  They trust some devices, some services, not others.  They choose to
use an app and to trust it.  They add it to their TCB.

Who are we to tell them that they have everything wrong?




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

Again, I frame it this way: the user chooses to trust a vendor.  That's how
TCBs and users work.



> But I don’t want to jump to conclusions, I’ll wait for a more clearly
> defined security policy first.
>

It's not up to me to deliver one - although to be fair, one can see *hints*
of this in (say) Signal, where it attempts to block itself from being run
on "rooted" Android systems; however one can't put stuff like that into a
communications standard.  It belongs instead in an "application value
proposition".  It's part of Signal's sales pitch.




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


Wow.  You want to tie communications to real-life identities?


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

Oh, okay, so maybe you don't want to tie communications to real-life
identities, you're just saying that there's one principal-key-or-identity
per participant?  That would be fine, but then...

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

Okay, so what you're asking for is that an E2ESM must surface some
individual or joint identity token with which Alice can prove herself to
Bob, out of band, to assure trust?

That seems reasonable, but in some cases redundant - like, for instance,
Ricochet, where in order for Bob to communicate at all with Alice, he must
already have her Onion Address.  There's no other cryptography involved,
and the Onion Address is also a network endpoint.

There would be no other token, but then there would also be no intermediary
"vendor". This sounds good.

However: anyone who follows / is aware of Darkweb markets will also know
that they are regularly faked. The Onion Address - or indeed any static
per-client "identity key" for any participant - can and will be spoofed by
AliceFake1, AliceFake2 (etc) - so long as the Fake Alices do a good job of
social-engineering themselves into public awareness.

So such keys are a nice-to-have and will add a little extra assurance, but
I don't see mandating this as achieving anything other than an "extra layer
of indirection"?  The additional trust they provide is not quantifiable?

If it is, how is it measured?

    - alec

-- 
https://alecmuffett.com/about