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

Mallory Knodel <mknodel@cdt.org> Mon, 10 May 2021 16:01 UTC

Return-Path: <mknodel@cdt.org>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D6BA3A21D9 for <mls@ietfa.amsl.com>; Mon, 10 May 2021 09:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, 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=cdt.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id y-g3h8mXXogq for <mls@ietfa.amsl.com>; Mon, 10 May 2021 09:01:36 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 B1B803A21D6 for <mls@ietf.org>; Mon, 10 May 2021 09:01:36 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id c20so4822998qkm.3 for <mls@ietf.org>; Mon, 10 May 2021 09:01:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to; bh=GfU+YTPFu906on5PaPcjrrv8VZpxUy/90TrTUgpyJkI=; b=MmVriVO3Nxx1cmY/ivbSjObp/CSTn27YPaiKV0J2Yn80Wp7ptbBpQknKJAUMRRNvSR wsKY0CM4MX2oh/xZMJXh2dq7tcFnWVk3975Hte52FvgZCXXPeefk7wS73gjFmg+N4MJf B3NAjwrf0mP8pjfEOUvCgDGqSX7hUcsi8JtbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to; bh=GfU+YTPFu906on5PaPcjrrv8VZpxUy/90TrTUgpyJkI=; b=fREveJN9V4OyFTBc6H2Vw3MdOatc0JxNc+kuLKPIdVf6EkXof+IaIl6IfXz+A6qTki 6ykqVFWebVw2128ZCFk/NzMa2UWilDcXY9gAi/imzgDmMLfCGUWnnK2H3k5lPQVQqo8B j/xWx5Xxnwws20XKS1lvvUKnyaI8C8TMGHEXMxoNLbY8JvKj5GFqAEg8YCYakHQfXCtS oKfDAvYICUuZ4nBxTQY574o1gXsudUCu4Ugy1UtH9FXqMeZ3X4ETDc1ATk4xY94CbVcV KAKahOxOrR35aL0VjVMnFEtf5I8sBE5otC00z0OGPdLvzeggBMcYBVRctMFMxHV+Gx/d 2TAQ==
X-Gm-Message-State: AOAM531ej7VcfiKC5oB+qPeQBhWTeMDyqrO+b15qmlN9ihXRaRhlcJ6y MnoQEHthUrMmUDOUynCsaCI7NXHhahz+MLDC
X-Google-Smtp-Source: ABdhPJz5DTIv/05Y0VYQn8MkYey8+pDBOuTy7rjTl7swYHFG/HnW5OqBdySlqBd9QcdAUblxGh4PqQ==
X-Received: by 2002:a37:9547:: with SMTP id x68mr22952969qkd.474.1620662494610; Mon, 10 May 2021 09:01:34 -0700 (PDT)
Received: from ?IPV6:2601:140:8680:4c40:3161:a834:2760:43ad? ([2601:140:8680:4c40:3161:a834:2760:43ad]) by smtp.gmail.com with UTF8SMTPSA id m10sm10025441qtq.83.2021. for <mls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 09:01:34 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------zEuoJg0Ywb5rUbXlL0m0DuXY"
Message-ID: <a8e872c9-10b7-152d-b176-e15f65a0476f@cdt.org>
Date: Mon, 10 May 2021 12:01:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0
Content-Language: en-US
To: mls@ietf.org
References: <CAFWeb9LwdSecpQdM1zvTAht+DvnYf3NCD4tcte1ZcH-pjHFRnA@mail.gmail.com> <CAKHUCzxbnSfZoGGg-gWjuC1Bz0Av2Rh_o40_GPU_01cR7PwCmg@mail.gmail.com> <CAFWeb9Lra9F1qtmeDp=Z9DtwZgf-gGfTsZ3UG6VL+htvOa0t2Q@mail.gmail.com>
From: Mallory Knodel <mknodel@cdt.org>
In-Reply-To: <CAFWeb9Lra9F1qtmeDp=Z9DtwZgf-gGfTsZ3UG6VL+htvOa0t2Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/tikaqzIryPxtTkGW2kSb2URK36w>
Subject: [MLS] secure & end Re: 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 16:01:42 -0000

Hi all,

On 5/7/21 9:49 AM, Alec Muffett wrote:
>     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".
> That *is* an objection, however it pivots on the assertion that I am 
> somehow attempting to define "secure" - but I am not.

Alec, I thought I'd respond to your points about adversaries and 
security in my draft by picking up on this theme further up in the 
thread on your draft.

This highlights a fundamental difference in approach. And there are two 
ways I look at it:

The first is how tech is defined. Is a technological thing defined by 
its features, or should we describe outputs that can be achieved by the 
technology we use? Both are fine. But in draft-knodel-e2ee we take the 
former approach. And if you're trying to define security, or what it 
means to be secure, in your draft then you're clearly taking the latter 
approach. Again, the former is meant to be rather objective, for users 
to do with it what they will (eg here's what it does, determine if this 
will give you the output/security that you want). The latter approach 
means you're describing utopia and maybe that gives developers some 
ability to navigate towards that ideal, which is why its a valuable 
approach but a different one. Certainly harder!

The second is specifically concerning tech that is built for security 
and/or privacy by design. We don't need to rely on the idea of an 
adversary in order to make, and therefore describe, a technology. 
Privacy and security, and other side benefits like access to info, are 
fundamental for all people. That intersection happens at technology use, 
which certainly has its place within the realm of technology development 
in terms of feedback loops between developers and users (ideally this 
loop is as tight as possible). But we are talking at the level of 
definitions, not implementations. This is very far from use. We should 
be able to define what is a technology (eg secure messaging or 
encryption) without invoking specific threats, and rather using threat 
modeling to trouble our definitions and designs. I would threat models 
help to problematise designs and definitions, rather than explicitly 
centering them in the description. In draft-knodel-e2ee we intentionally 
chose not to invoke an adversary but rely instead on lessons learned 
from encryption technologies that have modeled threats.

Before I close, in general I've been waiting to make a comment about the 
choice to define secure messaging instead of encryption, because I think 
these previous two analyses lay the groundwork for what I'm about to 
say. That is: from a user perspective, having the two terms coexist is 
the first problem. Say there are apps that successfully implement 
something like client-side scanning or traceable messages. Which is that 
app-- secure messaging or encryption? It's not easily discernible for 
the user. There's too much parity between them for any meaningful 
distinction to be possible with basic inference. "Secure messaging" at 
the moment in the industry is simply a descriptive phrase, not a 
rigorously defined technology and I think it should stay that way. OTOH 
encryption is specific. Encryption means something and it needs a 
rigorous definition in order to not have the meaning of e2ee broadened 
to include things that it really shouldn't include. This is the second 
problem, that the lack of clarity be used as a vector for attack on the 
integrity of an important technology: encryption.


Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780