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

[Raphael Robert <[e-mail]>]

Thanks for the additional context, it certainly helps!

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.

Regarding the definition of an “end”, draft-knodel-e2ee-definition-01 has section 2.1, 4.3 & 4.5. Your draft has section 4.1 & 5. In my mind both drafts could be a bit more assertive here. 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. Other humans who are not part of the “conversation”? Future participants of the “conversation”? A machine that will scan the message content and act on it? In the end this defines what “confidentiality” really means, besides the academic definition.
To be more precise, I would add to the definition of participants, that all participants must know exactly the type of other participants. It matters whether participant Eve is a bot or a human. This would be an actionable definition in order to refute that a system with ghost user is still e2e secure. If a participant lies about the kind of participant they are, this would constitute a breach and contradict the end user expectations.

> On 7. May 2021, at 18:22, Alec Muffett <[e-mail]> wrote:
> 
> Heya!
> 
> All references in the attached, are against: 
> 
> URL: https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end-secure-messaging.txt <https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end-secure-messaging.txt>
> 
> ...which should be constant even if the document is subsequently updated.
> 
> 
> On Fri, 7 May 2021 at 15:50, Raphael Robert <[e-mail] <mailto:[e-mail]>> wrote:
> 
> I agree that the two drafts a quite different. Yours is much more specific in certain aspects. And this is where it also gets tricky :)
> Dave has a good point that it might not be straight forward to have a “one-size-fits-all” model. 
> 
> This is not a one-size-fits-all model of "security".  It's a definition of end-to-end secure messengers".  
> 
> It is a formalisation of the following argument:
> 
> 1/ in an "end-to-end secure messenger", there are "ends"; this flows from the expression
> 
> 2/ messages are sent from "ends", to "ends", and a sequence of messages constitutes a "conversation" (obvious?)
> 
> 3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) to the current & wholly visible set of conversation "ends" (3.2) ; if it were not frozen thusly we would lack forward secrecy and simply be reinventing Yahoo Messenger, which wasn't end-to-end secure, hence we can't be doing that
> 
> 4/ no "end" may have privileged access to content, (3.1 - participating as an 'end' does not somehow bestow exceptional access to content, e.g by also being a database administrator)
> 
> 5/ no "non-end" may have any access to content (3.3.2)
> 
> 6/ it requires the consent ("intentional action") of an existing member, to add more "ends" to a conversation (3.4) 
> 
> 7/ the software should help ends understand where they are logged-in (3.5)
> 
> That's it.  That's the whole specification, although it's padded with stuff like "indistinguishability" to disambiguate questions like "what if we just leak a *little* bit of the content?" and "what about conversation metadata?". 
> 
> Everything extrapolates from the term "end to end secure messenger", and I would be interested to hear examples of purportedly "end-to-end secure messengers" which don't already meet it.  I would like to know why they do not?

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).

> 
> 
> draft-knodel-e2ee-definition-00 is much broader could certainly be expanded to include more precise definitions to illustrate the more abstract notions.
> 
> And there's the rub; the point of this is to avoid abstract notions, because we need a concrete definition in order to judge what is meant by "end to end secure messenger" - not to mention to measure the features which some states propose be drilled into them.
> 
>  
> Just having fixed set of precise criteria sounds nice in terms of simplicity but might simply prove to be insufficient to capture all valid use cases.
> 
> I welcome examples of use-cases where this definition falls short.

I don’t have a good counter-example at hand, but that doesn’t mean it doesn’t exist. I guess it would be great if we had links to existing literature, or comparative analysis of past and current e2e secure systems to corroborate the idea.

> 
> Notably this definition also works for Ricochet which uses Tor Onions and point-to-point communication to provide end-to-end security, without even a hint of content encryption. It turns out that it is not always necessary to use content encryption (e.g. Signal Protocol) to implement a "closed distribution list" for a sequence of messages - which is all that "end to end security" is, in the most fundamental sense.  The technologies have to adapt in order to address the underlying architecture: client-server, direct peer-to-peer, mesh, etc.
> 
> 
> In either case, having a document that can be used as a checklist to determine with absolute certainty whether a system is end-to-end-encrypted or not sound like a dangerous endeavour.
> 
> I would welcome examples of the dangers.

In a way this is what Dave pointed out earlier. 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.

>  
> Given the complexity of the subject, the answer cannot always be binary.
> 
> Certainly it cannot yet be binary, for want of a metric to measure against.

My hunch here is that either draft could evolve into something that — when used as benchmark — gives a high degree of confidence whether a system is e2e secure or not.
In a way it would be like a legal document: it tries to be as precise as possible, but there might still be the need for interpretation by experts in the field (including the possibility of disagreement).

>  
> When you say “ill-defined, but widely used terminology”, what exactly are you referring to?
> 
> "End"; I would be interested to hear what your definition of this term is, and so we might compare it to Section 4.1 and the explanatory note in Section 5,
> 
> 
> Statements in the press? What exact problem needs fixing here?
> 
> The issue is that "end to end secure messenger" has no definition against which we can measure the features of a given software solution.  This I-D offers one.
> 
> And then, when the UK Government (or other) propose that "...adding a 'Ghost' will not break end-to-end security", we can precisely measure the impact of, and rebut, that statement.

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. 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.
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. They are de facto different now, but maybe it would be worth trying to bring them together? I am an author of neither, so I can really only float the idea.

Another aspect that is at least partially covered in draft-knodel-e2ee-definition-01 is that of authentication. I think this plays a big role when it comes to “ghost users” and transparency of participants. It’s also something that is still very much an area of exploration for secure messengers. There is room for improvement across the board and in that sense the drafts could serve as a guideline for existing and future messengers.

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

Raphael

> 
> 
> Having a bit more context on that would certainly help with the overall assessment. Maybe we are just talking past each other.
> 
> I hope this helps.
> 
>     - alec
> 
> -- 
> https://alecmuffett.com/about <https://alecmuffett.com/about>
>