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

[Alec Muffett <[e-mail]>]

On Mon, 10 May 2021 at 17:01, Mallory Knodel <[e-mail]> wrote:

> 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.
>
Hey Mallory! Thank you!

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?
>
This is also how I am looking at it - to rephrase: your draft pursues
whether something *looks* like E2E, and mine is busy with whether it *swims
and quacks <https://en.wikipedia.org/wiki/Duck_test>* like E2E; and I am
trying to formalise what swimming and quacking entail.

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).
>
There's the rub: just because it has confidential feet and trustworthy
feathers, doesn't make it an E2E duck in the modern era; the folks at GCHQ
love to say stuff like "of course the messages are confidential; people can
have *confidence* in them, we just need to be able to get at them" - and
other games like that (ref:
https://www.lawfareblog.com/principles-more-informed-exceptional-access-debate
)


> The latter approach means you're describing utopia
>
Ha! I seem to be describing the norm, rather than some utopian ideal - as
suggested by work in progress at:

https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyEJHRUZyqQ/edit#gid=0

The definition even fits both Signal *and* PGP-over-Email, which latter
does not suit the modern era but there's nothing to be done about that. The
point of the draft-muffett-e2esm definition is to be precise, not
"appropriate".

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!
>
Developers are not my target market; if anything I think that
draft-knodel-e2ee-definition-01 is better for developers, highlighting
abstract concepts like:

*"A system provides message confidentiality if only the sender and intended
> recipient(s) can read the message plaintext" *


...yet leaving open the concepts of "intended recipients" (GCHQ love to
play with this) and "what does 'read' mean?" and "is the writer a reader?"
and "whether the 'intended recipients' *really* need to see each other?"
and "whether an additional intended recipient can be silently added?" and
"do we need to hide the plaintext size? Yes(3) or No(2)?"

There is space for defining principles, and there is also space for fitness
testing.  I am aiming for the latter.


> 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.
>
Slightly disagree.  What we need is a threat model, and fortunately one can
be straightforwardly extrapolated from the concept of "end to end". The
concepts of security and privacy are meaningless without a threat model,
and a threat model is informed by understanding the motivations of a threat
actor.... but it appears that you *agree* with me on this, maybe:

> 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
>
I'm not quite sure of your meaning here, but... direct threat modeling
works for me, including the "meta" threat-modelling:

- there are people who will try to bend this definition for political aims

- there are people who will redefine words in this definition for political
aims

- there are people who will use any crack in this definition, for political
aims

This is why draft-muffett-e2esm attempts to lock down terminology at a
technical (not "intentional") level of "what this means", because such is
*measurable*.

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.
>
My intent is to rigorously and clearly define end-to-end secure messaging,
and my solution to "E2E brand dilution" has been improved in section 2 of
Draft-01, as a flat statement:

*2. Requirements for an End-to-End Secure Messenger*
*Software which functions as an End-to-End Secure Messenger MUST satisfy
the following principles, and MUST satisfy these principles in respect of
the provided definitions for all forms of communication and data-sharing
that the software offers. The software MAY comprise either a complete
application, or a clearly defined subset of functionality within a larger
application. Any software that does not satisfy these requirements is not
an End- to-End Secure Messenger, and it does not implement End-to-End
Secure Messaging, nor does it implement End-to-End Encrypted Messaging.*

Which I think is clear enough. E2ESM is a superset of E2EM, and I am sure
that over time, Ricochet will not be the only messenger that implements
E2ESM without requiring a central (or, distributed) "provider".  Briar
kinda does, too, and I am not sure about Cwtch yet.

Optimistically, though: all these challenges are addressable.

Perhaps the greatest challenge is obtaining consensus regarding the
importance of "quacking".

    - alec
-- 
https://alecmuffett.com/about