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

[Alec Muffett <[e-mail]>]

On Fri, 7 May 2021 at 21:43, Raphael Robert <[e-mail]> wrote:

> Thanks for the additional context, it certainly helps!
>

I'm glad! I want to see this - or something better than it - succeed at
providing a measuring stick for what constitutes an end-to-end secure
messenger, be it one that uses client-server architectures with data at
rest on a central server; or one that uses secure point to point
networking, or even mesh-networking like Briar.

The fundamental realisation was that "end-to-end" is basically synonymous
with "closed distribution list with no 'blind' membership"; then it's
simply a matter of describing that.


I definitely think it is worth attempting to capture the aspects of what
> could constitute and end-to-end secure messaging system. I’m only arguing
> about the details here, not the effort in general. I also want to add that
> I can’t claim to be aware of all prior literature on that subject, so I
> like the fact that draft-knodel-e2ee-definition-01 cites a few sources.
>

I have a few sources, too, but the summary in my previous email appears
obvious to me; once one stops looking at "E2EE" and starts looking at the
generic pattern of "E2ESM", it seems to just flow from the description.


[...] I like that you introduce different types of participants. I think
> that point is particularly important, because if the participants are not
> just “humans with a messenger app”, it begs the question who has control
> over the messages that were received by that participant.
>
[...]

> To be more precise, I would add to the definition of participants, that
> all participants must know exactly the type of other participants.
>

I take your point; I did actually consider that for a while - there would
be benefits to being better informed about the other "participants" - but
eventually I rejected the proposition as being intrusive and impractical to
mandate/require, although there's certainly opportunities for some
platforms (?) to offer such information if they choose.

To explain:

I don't really "introduce different types of participants'', instead I
merely "allow" that they exist; it is fine for one participant to be a
human being, another to be an autoresponse bot, and the third to be a
conversation-archiver.  The important point is that none of them are
"invisible" to other participants as would be the case with a "ghost", nor
may there be a "ghost outside the machine" accessing content (PCASM) by
means of a back door.

However the participants MUST be able to see each other, and... from that,
how far should we go in terms of visibility?

Should "Signal" be required to disclose to the other participants in a
conversation that I use both my Phone AND ALSO that I use Signal Desktop on
two separate devices?

Should WhatsApp be required to highlight when I am using WhatsAppForWeb in
a browser, rather than my primary device?

I decided that these questions are beyond the scope of defining End-to-End
Secure Messaging, not least because they are heavily platform specific -
for Signal the entity is represented by a cryptographic key with several
devices, whereas WhatsApp uses a on-phone identity and (roughly) all other
WhatsAp "clients" call back to the phone for session keys.



> It matters whether participant Eve is a bot or a human.
>

It does... and it does not, because to pursue that goal requires us also to
get into (say) WhatsApp-For-Business with Bot-Augmented-Human-Clusters,
etc. This is why...



> This would be an actionable definition in order to refute that a system
> with ghost user is still e2e secure.
>

...this is why the standard is written:

1/ To see plaintext content, the viewer must be a participant (for a given
message)
2/ Participants (at the time of composition) must all see each other, so
they know who could see their message(s)
3/ Anyone who is not a participant, MUST not see plaintext content

This kills "Ghosts" because they cannot be invisible, and they cannot
access plaintext from outside of the conversation "walls".

The question of whether the visible user "User:XenaWarierPrinces" is a
human, bot, or some kind of bot-human hybrid, is a social question, and
best left to the platform.



> If a participant lies about the kind of participant they are, this would
> constitute a breach and contradict the end user expectations.
>

That strikes me as a matter for a per-user Acceptable Use Policy, and -
being a matter of intent - rests outside the scope of defining howan
End-to-End Secure Messenger should behave.


A little higher-up you observed:

Regarding the definition of an “end” ... In my mind both drafts could be a
> bit more assertive here


I feel my definition is sharp. and clear, because I leverage "Trusted
Compute Base" as a concept.  This is a bit of a punt, but it flows directly
back to my question "Should WhatsApp be required to highlight when I am
using WhatsAppForWeb?" - because if it were obligatory for a platform to
surface that I *do* use WhatsAppForWeb, perhaps it should also surface what
browser I am using, and at what patch level?

So: for the purposes of having a viable standard, it is necessary to accept
that all participants - human, bot, spook, recorder, malicious, kind - are
equal participants, and that the bounds of their usage is defined by what
*THEY* consider to be "secure". To not accept this would put us in the
realms of "Ranum's Law", viz: that this is a social problem and you can't
solve social problems in software.


I think what both drafts don’t fully cover yet is the fact that end users
> have expectations. For me everything extrapolates from the “set of typical
> end user expectations”. The software and its documentation should make it
> as clear as possible to the user how the system works, who can potentially
> have access to messages (e.g. a LE ghost user, a recording bot, only other
> humans that can be transparently authenticated out-of-band).


I am delighted for users to have expectations, and I look forward to
learning how their expectations negatively impact this standard other than
in terms of omission that is arguably not better dealt with at a non-RFC,
platform-differentiation level.


There could be both false positives and false negatives.
> False positive: A system that works in a way that doesn’t contradict the
> definitions of the draft, but that contradicts the typical end user
> expectations.
> False negative: A system that contradicts one or more definitions of the
> draft (most likely because they are too restrictive) but still meets the
> typical end user expectations.
> False positives are downright dangerous for end users, while false
> negatives might hinder the adoption of an otherwise great system.


I look forward to concrete examples, and will work to adapt the
specification to fit them where it makes sense.


I understand you want something actionable with punchy definitions and I
> agree that it would be a useful thing to have. For it to become that, it
> needs consensus from the wider community.


I wish to share these perspectives with the wider community, in order to
pursue consensus.  That is why I am investing this effort.


Not only because that’s the idea behind IETF, but also because it carries
> more weight in the end. With that in mind, it would be great if some more
> folks would chime in so that this is not only two party conversation with
> only two opinions.


I would be delighted to hear and address perspectives from others.


What I’m also not sure about is whether the two drafts will be sufficiently
> different in the end, in the sense that they would cater to different
> audiences.


We shall certainly see; at the moment I am a househusband with plenty of
spare time to dedicate to this effort, so I have ample resource to dedicate
towards building a consensus definition.


Another aspect that is at least partially covered in
draft-knodel-e2ee-definition-01
> is that of authentication.


That is an interesting concept: whether the entity can somehow be linked to
an external identity namespace; as we see from arguments about Signal's use
of "phone numbers" as an identity principal - and that some people detest
their doing so - it's not a required feature of End-to-End Secure
Messengers, and so will not appear in this specification.


I think this plays a big role when it comes to “ghost users” and
> transparency of participants.


This is really interesting; I am getting the sense that you are strongly
drawn to the notion of "real" or "genuine identity" being part of an
end-to-end secure messenger solution.

Would that be correct?


Lastly I also would like to mention the MLS architecture draft (
> https://tools.ietf.org/html/draft-ietf-mls-architecture-06) that touches
> on a lot of these subjects.


Indeed, I think that you and I last met at a MLS shindig hosted at Facebook
some years ago :-)



> While its purpose is a different one, it goes strictly beyond the scope of
> MLS and highlights aspects that are relevant for many secure messaging
> systems.

I hope the above makes it a bit more clear what I maybe failed to express
> earlier.


It is really interesting, and I am grateful for the pushback and the
opportunity / spark to explain. :-)

    - Alec


https://alecmuffett.com/about