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

Dave Cridland <dave@cridland.net> Fri, 07 May 2021 12:53 UTC

Return-Path: <dave@cridland.net>
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 F35D53A1FB5 for <mls@ietfa.amsl.com>; Fri, 7 May 2021 05:53:32 -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, 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 (1024-bit key) header.d=cridland.net
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 x8FX7C3xt_L1 for <mls@ietfa.amsl.com>; Fri, 7 May 2021 05:53:28 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 E6DD23A2000 for <mls@ietf.org>; Fri, 7 May 2021 05:51:59 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id d11so9138465wrw.8 for <mls@ietf.org>; Fri, 07 May 2021 05:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82TphbPngo3Y6XvbD04BkzMUKPIaaSCdcRvwlROZGUQ=; b=Bbb1ihFEIT+3MjxzMMN1smA3tXoD1P36Rz1qBGRZYw4vBu11WCapCZZuYPHABhGZBY 6NtpbiEUgTkoLltsWGXQUIHx1fNF4NnG/wVNzeLJIG6Gu1M6p6FucG4DTmqMz1C0ypqu yf8jixyiKFLATFjdAYU76sFUEyksmi3Pgpb0w=
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=82TphbPngo3Y6XvbD04BkzMUKPIaaSCdcRvwlROZGUQ=; b=ZNwJbCjvKPJ/i7QCmjDOh4lki0H2UeL4Xzf7wnkX68lzbMxFToXzQEnO2Fhlus8SeI fO3dJ4e2hjtSsdiYBpkZ/6H1V+5gr/4zX4xysVWJnYbGgQzdWMVnao6Be9yC5jzSufgS hu+QbSBwnr4+ZMw9v2z92Wdbe98mYe7XsC7aeTVCCoykd31nS9i6dSSiQSUpLFxabSH2 Pl4MJL2MYe5vlyaV90rHPDWmuATLAoPT1ijI12j+SeNj8FG6dgYAxpYmxf6nLtkcvkTI lrzFs7de70ZU7stPgnw50xUPQlfUQZTmA82qZ7FE9GLxwqZJUNV0ft/zs7sz7yutvbRw N5ng==
X-Gm-Message-State: AOAM5330OkbQnMPu+K6lAUUr5AoNhRkczNVALLGLnY5SkPioyvVS/KdE Ug8tkGGkMl8m5OXMJLb/zO6BRIqgeIVke7Rj/kv27w==
X-Google-Smtp-Source: ABdhPJwyPnNWDgC5DGL5xnUz/XEOoji+UaT61a7ucwSb9fy71X/2AXiNrd2schrp1eRsCfAypFztEIO6V3fbiO/7Nyc=
X-Received: by 2002:a05:6000:1b06:: with SMTP id f6mr12075117wrz.339.1620391917836; Fri, 07 May 2021 05:51:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com>
In-Reply-To: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
Date: Fri, 7 May 2021 13:51:47 +0100
Message-ID: <CAKHUCzxbnSfZoGGg-gWjuC1Bz0Av2Rh_o40_GPU_01cR7PwCmg@mail.gmail.com>
To: Alec Muffett <alec.muffett@gmail.com>
Cc: mls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a8ecbf05c1bce422"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/z04QRi75hU9ZBceBXRq1t7MaGV0>
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 12:53:33 -0000

Hi Alec,

On Thu, 6 May 2021 at 18:57, Alec Muffett <alec.muffett@gmail.com> wrote:

> What do you think, please?
>

As I said on Twitter, I'm hesitant to try to build a one-size-fits-all
definition of "secure". I think a much more useful first step (and one
where consensus is much easier to gain) would be to talk about different
threats and their potential mitigations and trade-offs, rather than
blanket statements that things are or are not secure in some absolute sense
which I'm unconvinced exists. "Secure" is not an absolute, and has to be
handled in context. MLS provides a (very) useful set of tools with which to
build various models of secure, including the consumer-grade personal
security you appear to be driving toward.

The primary objection I have here is that people will make the assumption
that any system that does not conform to your arbitrary definition of
"Secure" is, by inference, "Insecure".

As an example, consider §3.3. I currently write instant messaging
applications for the NHS (the UK's National Health Service, its
overwhelmingly dominant health provider) as well as others, for clinical
messaging. This obviously needs to be secure. Your stipulation is that
clinicians joining a particular group chat must not be able to see past
messages. This in turn means that clinicians must be ill-informed about the
patient's past, and therefore there is a heightened clinical risk to the
patient. I would argue that patient safety should be an outcome of an
applicable security stance. I think there is genuine risk involved in
providing people with a misleading single definition of "secure".

This is not to say that your definition is particularly "wrong"; it's not
capable of being wrong for the same reason that it's not capable of being
"right".

Dave.