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

[Mallory Knodel <[e-mail]>]

Hi,

On 5/7/21 4:43 PM, Raphael Robert wrote:
>
> 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.

We just added a new section to accommodate for this. It's particularly 
important because if you look at the various attempts to modify e2ee 
such that third parties can know things about the messages, there is 
play with the notion of end. Client-side scanning is a real proposal and 
putting that feature within an app would be awful, but better than 
putting it in the OS, for example.

But we still need to improve this section. I would really love for 
someone to propose some text changes here to make it as strong as it can be.

-Mallory

> 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
>>
>> ...which should be constant even if the document is subsequently updated.
>>
>>
>> On Fri, 7 May 2021 at 15:50, Raphael Robert <[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) 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
>>
>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls

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