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

[Mallory Knodel <[e-mail]>]

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

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