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

Alec Muffett <alec.muffett@gmail.com> Fri, 07 May 2021 16:23 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 6C5773A2877 for <mls@ietfa.amsl.com>; Fri, 7 May 2021 09:23:43 -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, 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 (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 BlDLemXSArho for <mls@ietfa.amsl.com>; Fri, 7 May 2021 09:23:38 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 EB1D13A2872 for <mls@ietf.org>; Fri, 7 May 2021 09:23:36 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id i17so9003342qki.3 for <mls@ietf.org>; Fri, 07 May 2021 09:23:36 -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=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=YYCA9+LSuCY8d4tlQRm/LoUU/InQK1jZowNGeAVVb9+Z2G3t2H/PJaxtOq5GjHIMKn SLxo7EtlZH8Kvg2CGlOhyREfDMtiPdAl2j53w40510xps1C+zSh6nBQCtr1V7VMycbmq LSzfzVRXMvQYrpg7tKRCPuuD8CaMVODSKqx50LNLdu0ozih1tC1QXhQAlVtz5q/UJFu6 /Xjbv6aGlV2R8XQAj2ZAjkFVricvktgJP5SkSTwrtWSYDea2y+sGGMHE+CzjfGVb4Mfv VEoGrVeLfqaMqyDvGoXHAkcDT0EpeH307GyDC/mbcCX6W7kyyLNWeacvuMKDyxol2cHU S4zw==
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=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=O9pk3sT6rMuriNFkjviKg4i1NOBZgM0VXgkB6A62S3ORDMhRhf+rNAfyLxmKG4ieIj FvZP7iqwQOX/ZVvstz6trwUEhbv1TsHkN1/5ChvJx+DEoi6mTKzoHbx0fJTYdrfGq+9D 1/b7+SIx6gk9bcd+J6dChnQeM90BBTtQeMb6S0ws27hIv8BjCeUuxJ5wRgYG6jBdI/2M FkraCjwPWwU4jjpbrgrMiXKHEtYJhT3OzkJLzWm86iN9PiErXjS/W4wbB46GXKjel+IQ 0Gzw3iQi/59S4XlK94vwu71pctUrpq87ELX5Xn73zfr7IQlmPPoG01d7ME+TbmvZqXlk hrBw==
X-Gm-Message-State: AOAM5339FxnsqK80D02LjkGAw6hyuSq3L3Ypwk6p4ITjykqSTPh6YgYF WbeV7FfJAfJ7DcT4s3vQQCJiR2s3FCVeYgEg7YYuT7aAI3jASg==
X-Google-Smtp-Source: ABdhPJyboK2Za/zI5LPRFUbuKs02CkHwhSRctpYo1bqbTrDZzy+Id1RAqEHwAdIDOQ15RLy2pwGOiSl/pjEaYyIQ6PI=
X-Received: by 2002:a05:620a:127b:: with SMTP id b27mr10055641qkl.104.1620404614005; Fri, 07 May 2021 09:23:34 -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>
In-Reply-To: <E418B2DA-D0E3-473A-A8A1-3248766A90DF@raphaelrobert.com>
From: Alec Muffett <alec.muffett@gmail.com>
Date: Fri, 7 May 2021 17:22:57 +0100
Message-ID: <CAFWeb9LgU+eC0FVndeY-6Kf=NNUf4Lmdhuy2nKXwyK9gDE8UHg@mail.gmail.com>
To: Raphael Robert <ietf@raphaelrobert.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006907aa05c1bfd9d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/m7j5lfP-kKLJWPkYOI7SeCbk7Yo>
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: Fri, 07 May 2021 16:23:44 -0000

Heya!

All references in the attached, are against:

URL:
https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end-secure-messaging.txt

...which should be constant even if the document is subsequently updated.


On Fri, 7 May 2021 at 15:50, Raphael Robert <ietf@raphaelrobert.com> wrote:

>
> I agree that the two drafts a quite different. Yours is much more specific
> in certain aspects. And this is where it also gets tricky :)
> Dave has a good point that it might not be straight forward to have a
> “one-size-fits-all” model.
>

This is not a one-size-fits-all model of "security".  It's a definition of
end-to-end secure messengers".

It is a formalisation of the following argument:



*1/ in an "end-to-end secure messenger", there are "ends"; this flows from
the expression*


*2/ messages are sent from "ends", to "ends", and a sequence of messages
constitutes a "conversation" (obvious?)*


*3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) to
the current & wholly visible set of conversation "ends" (3.2) ; if it were
not frozen thusly we would lack forward secrecy and simply be reinventing
Yahoo Messenger, which wasn't end-to-end secure, hence we can't be doing
that*


*4/ no "end" may have privileged access to content, (3.1 - participating as
an 'end' does not somehow bestow exceptional access to content, e.g by also
being a database administrator)*


*5/ no "non-end" may have any access to content (3.3.2)*
*6/ it requires the consent ("intentional action") of an existing member,
to add more "ends" to a conversation (3.4) *



*7/ the software should help ends understand where they are logged-in
(3.5)*That's
it.  That's the whole specification, although it's padded with stuff like
"indistinguishability" to disambiguate questions like *"what if we just
leak a *little* bit of the content?"* and *"what about conversation
metadata?".*

Everything extrapolates from the term *"end to end secure messenger"*, and
I would be interested to hear examples of purportedly "end-to-end secure
messengers" which don't already meet it.  I would like to know why they do
not?


draft-knodel-e2ee-definition-00 is much broader could certainly be expanded
> to include more precise definitions to illustrate the more abstract
> notions.
>

And there's the rub; the point of this is to avoid abstract notions,
because we need a concrete definition in order to judge what is meant by
"end to end secure messenger" - not to mention to measure the features
which some states propose be drilled into them.



> Just having fixed set of precise criteria sounds nice in terms of
> simplicity but might simply prove to be insufficient to capture all valid
> use cases.
>

I welcome examples of use-cases where this definition falls short.

Notably this definition *also* works for Ricochet which uses Tor Onions and
point-to-point communication to provide end-to-end security, without even a
hint of content encryption. It turns out that it is not always necessary to
use content encryption (e.g. Signal Protocol) to implement a "closed
distribution list" for a sequence of messages - which is all that "end to
end security" is, in the most fundamental sense.  The technologies have to
adapt in order to address the underlying architecture: client-server,
direct peer-to-peer, mesh, etc.


In either case, having a document that can be used as a checklist to
> determine with absolute certainty whether a system is end-to-end-encrypted
> or not sound like a dangerous endeavour.
>

I would welcome examples of the dangers.



> Given the complexity of the subject, the answer cannot always be binary.
>

Certainly it cannot *yet* be binary, for want of a metric to measure
against.



> When you say “ill-defined, but widely used terminology”, what exactly are
> you referring to?
>

"End"; I would be interested to hear what your definition of this term is,
and so we might compare it to Section *4.1* and the explanatory note in
Section *5*,


Statements in the press? What exact problem needs fixing here?
>

The issue is that "end to end secure messenger" has no definition against
which we can measure the features of a given software solution.  This I-D
offers one.

And then, when the UK Government (or other) propose that "...adding a
'Ghost' will not break end-to-end security", we can precisely measure the
impact of, and rebut, that statement.


Having a bit more context on that would certainly help with the overall
> assessment. Maybe we are just talking past each other.
>

I hope this helps.

    - alec

-- 
https://alecmuffett.com/about