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

From: Alec Muffett <[email-masked]>
Date: Thu, 6 May 2021 18:56:55 +0100

Hi All,

I am drafting an I-D to offer a measurable definition of End-to-End Secure
Messaging, including End-to-End Encrypted Messaging.

It's basically a "Duck Test" for End-to-End Secure Messengers: "Does <this
software> quack like an E2EE-Secure Messenger, should?"

I believe that such a definition is a long-overdue necessity for settling
arguments such as "Would adding a Ghost participant *really* break
End-to-End Security" (answer: "yes").

I think that the MLS group might be a good workgroup for such a document.

What do you think, please?

Current draft text:
https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.txt

As HTML:
https://htmlpreview.github.io/?https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.html

    - Alec

--
https://alecmuffett.com/about

---

From: Raphael Robert <[email-masked]>
Date: Fri, 7 May 2021 10:40:34 +0200

Thanks for sharing!

You mention the prior art by Knodel et al. at the end and I’m wondering if it wouldn’t be a better starting point for discussion? Especially since it has the advantage of building upon notions that are well-defined and established in the industry.

I’m also still struggling with your definition of a “backdoor” in 4.4:

'A "backdoor" is any intentional or unintentional mechanism, in
respect of a given message and that message's set of participants,
where some PCASM of that message MAY become available to a non-
participant without the intentional action of a participant.’

You previously mentioned that intent is hard to measure and I agree with that. But I’m quite convinced a design or implementation flaw shouldn’t be called a “backdoor” until there is sufficient proof of intent. If you call it a “backdoor” right from the beginning, most people will assume that intent was there. This would be very discouraging for everyone who contributes to E2EE protocols, because it introduces the risk of being stigmatised as someone with (criminal) intent just because an honest mistake was made. Long story short, I strongly reject that notion of a “backdoor” for being intimidating.

That being said, discussion around these topics is a good thing and I’m curious to hear other people’s thoughts!

Raphael

> On 6. May 2021, at 19:56, Alec Muffett <[email-masked]> wrote:
> 
> Hi All,
> 
> I am drafting an I-D to offer a measurable definition of End-to-End Secure Messaging, including End-to-End Encrypted Messaging.
> 
> It's basically a "Duck Test" for End-to-End Secure Messengers: "Does <this software> quack like an E2EE-Secure Messenger, should?"
> 
> I believe that such a definition is a long-overdue necessity for settling arguments such as "Would adding a Ghost participant *really* break End-to-End Security" (answer: "yes").
> 
> https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.txt <https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.txt>
> 
> As HTML:
> https://htmlpreview.github.io/?https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.html <https://htmlpreview.github.io/?https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.html>
> 
>     - Alec
> 
> --
> https://alecmuffett.com/about <https://alecmuffett.com/about>_______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Alec Muffett <[email-masked]>
Date: Fri, 7 May 2021 13:13:00 +0100

Hey Raphael!

Those are great questions, and I have already updated the draft to address
the latter one, but will paste the explanation here, too.

On Fri, 7 May 2021 at 09:40, Raphael Robert <[email-masked]> wrote:

> Thanks for sharing!
> You mention the prior art by Knodel et al. at the end and I’m wondering if
> it wouldn’t be a better starting point for discussion?
>
Especially since it has the advantage of building upon notions that are
> well-defined and established in the industry.
>

I feel that there need to be two separate approaches;
*draft-knodel-e2ee-definition-00* focuses deeply upon platform "goals"
qualitative provision of end-to-end *encryption* solutions, rather than to
specify what is necessary for an end-to-end secure (via
client-server-centric encryption, or otherwise) messenger solution to be
worthy of the (currently ill-defined, but widely used) terminology.  It
describes "scanning" rather what the effects of "scanning" would look like;
it describes "not allowing pattern inference" but remains open to someone
redefining what "inference" means, as opposed to leveraging
"indistinguishability" for a concrete definition.

There is a lot of overlap, but in the end
https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5
leaves the applied definition of E2E-Encryption somewhat open, whereas
draft-muffett-end-to-end-secure-messaging-00 is essentially a long and
nitpicky way of saying "If you're gonna call something end-to-end secure,
here is what 'end' means, and you will need to respect your ends."

Obviously with enough discussion and rewriting it would be possible to
somewhat merge the two documents, but since they take separate routes
towards addressing the matter, I am inclined to see both go forward and see
how their utility compares.

> ...
> You previously mentioned that intent is hard to measure and I agree with
> that. But I’m quite convinced a design or implementation flaw shouldn’t be
> called a “backdoor” until there is sufficient proof of intent. If you call
> it a “backdoor” right from the beginning, most people will assume that
> intent was there.
>
This would be very discouraging for everyone who contributes to E2EE
> protocols, because it introduces the risk of being stigmatised as someone
> with (criminal) intent just because an honest mistake was made. Long story
> short, I strongly reject that notion of a “backdoor” for being intimidating.
>

I hear that you are worried about pejorative stigma of terminology, so let
me share the rationale that I've just added to the draft:

>
>
>
>
>
> *In software engineering there is a perpetual tension between the concepts
> of "feature" versus "bug" - and occasionally "misfeature" versus "misbug".
> These tensions arise from the problem of [DualUse] - that it is not
> feasible to firmly and completely ascribe "intention" to any hardware or
> software mechanism.The information security community have experienced a
> historical spectrum of mechanisms which have assisted non-participant
> access to PCASM. These have variously been named as "export-grade key
> restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and
> Meltdown), "law enforcement access fields" (Clipper), and "key escrow"
> (Crypto Wars).All of these terms combine an "access facilitation mechanism"
> with an "intention or opportunity" - and for all of them an access
> facilitation mechanism is first REQUIRED.An access facilitation mechanism
> is a "door", and is inherently [DualUse]. Because the goal of E2ESM is to
> limit access to PCASM exclusively to a defined set of participants, then
> the intended means of access is clearly the "front door"; and any other
> access mechanism is a "back door".If the term "back door" is considered
> innately pejorative, alternative, uncertain constructions such as
> "illegitimate access feature", "potentially intentional data-access
> weakness", "legally-obligated exceptional access mechanism", or any other
> phrase, all MUST combine both notions of an access mechanism (e.g. "door")
> and a definite or suspected intention (e.g. "legal obligation").So the
> phrase "back door" is brief, clear, and widely understood to mean "a
> secondary means of access". In the above definition we already allow for
> the term to be prefixed with "intentional" or "unintentional".Thus it seems
> appropriate to use this term in this context, not least because it is also
> not far removed from the similar and established term "side channel".*

...and to call out that last point, I find it particularly interesting to
compare "back door" to "side channel"; to me, neither are particularly
stigmatic until combined with an adjective to describe "intent".

I have a back door in my house.  It's not inherently evil.

    - alec

---

From: Dave Cridland <[email-masked]>
Date: Fri, 7 May 2021 13:51:47 +0100

Hi Alec,

> What do you think, please?

As I said on Twitter, I'm hesitant to try to build a one-size-fits-all
definition of "secure". I think a much more useful first step (and one
where consensus is much easier to gain) would be to talk about different
threats and their potential mitigations and trade-offs, rather than
blanket statements that things are or are not secure in some absolute sense
which I'm unconvinced exists. "Secure" is not an absolute, and has to be
handled in context. MLS provides a (very) useful set of tools with which to
build various models of secure, including the consumer-grade personal
security you appear to be driving toward.

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

As an example, consider §3.3. I currently write instant messaging
applications for the NHS (the UK's National Health Service, its
overwhelmingly dominant health provider) as well as others, for clinical
messaging. This obviously needs to be secure. Your stipulation is that
clinicians joining a particular group chat must not be able to see past
messages. This in turn means that clinicians must be ill-informed about the
patient's past, and therefore there is a heightened clinical risk to the
patient. I would argue that patient safety should be an outcome of an
applicable security stance. I think there is genuine risk involved in
providing people with a misleading single definition of "secure".

This is not to say that your definition is particularly "wrong"; it's not
capable of being wrong for the same reason that it's not capable of being
"right".

Dave.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 7 May 2021 14:49:58 +0100

Hey Dave!

Nice to follow up in long-form. :-)

On Fri, 7 May 2021 at 13:51, Dave Cridland <[email-masked]> wrote:

> definition of "secure".

But that's not what I am trying to do; I am trying to build a
one-size-fits-all definition of "end-to-end secure", which is pretty easy
to do because there's an inherent threat-model in the phrase "end to end".

It comes down to "there are ends. respect them."

> I think a much more useful first step (and one where consensus is much
> easier to gain) would be to talk about different threats and their
> potential mitigations and trade-offs, rather than blanket statements that
> things are or are not secure in some absolute sense which I'm unconvinced
> exists.
>

The set of threats is practically infinite, and as we're aware from
firewall design it is much more robust to work with an "allowlist" rather
than a "blocklist".  Hence this approach.

> "Secure" is not an absolute
>

I agree.

> and has to be handled in context.
>

And the context is "end to end", and - especially - "end" is a term that
many use and few strictly define.

MLS provides a (very) useful set of tools with which to build various
> models of secure, including the consumer-grade personal security you appear
> to be driving toward.
>

I am not driving towards anything other than a measurable definition of
"end-to-end secure messaging".

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

The document clearly states that it is a "Functional Definition of
End-to-End Secure Messaging"; perhaps you can suggest how to make that more
clear?

As an example, ... Your stipulation is that clinicians joining a particular
> group chat must not be able to see past messages. This in turn means that
> clinicians must be ill-informed about the patient's past, and therefore
> there is a heightened clinical risk to the patient. I would argue that
> patient safety should be an outcome of an applicable security stance. I
> think there is genuine risk involved in providing people with a misleading
> single definition of "secure"
>

That's a great question with a practical use-case, but to me it begs the
question of:

  "why is the system that you [Dave] are describing, appropriate to
describe as 'end-to-end secure'?"

- who are the ends?  Are the messages stored in such a way that they could
be accessed by a non-participant, for instance a database administrator?
Where is your forward secrecy, and how is what you describe somehow
different to (say) a security-hardened version of Facebook Messenger?

These are questions which really ought to be asked of *every* platform, and
they are *not* being asked, because we have no metric to measure against.
Hence this document.

> capable of being wrong for the same reason that it's not capable of being

I disagree, and I suggest that it is the very nature of your critique which
demonstrates the functional requirement for a metric like
draft-muffett-end-to-end-secure-messaging

    - alec

---

From: Raphael Robert <[email-masked]>
Date: Fri, 7 May 2021 16:50:29 +0200

> On 7. May 2021, at 14:13, Alec Muffett <[email-masked]> wrote:
> 
> Hey Raphael!
> 
> Those are great questions, and I have already updated the draft to address the latter one, but will paste the explanation here, too.
> 
> On Fri, 7 May 2021 at 09:40, Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks for sharing!
> You mention the prior art by Knodel et al. at the end and I’m wondering if it wouldn’t be a better starting point for discussion? 
> Especially since it has the advantage of building upon notions that are well-defined and established in the industry.
> 
> I feel that there need to be two separate approaches; draft-knodel-e2ee-definition-00 focuses deeply upon platform "goals" qualitative provision of end-to-end encryption solutions, rather than to specify what is necessary for an end-to-end secure (via client-server-centric encryption, or otherwise) messenger solution to be worthy of the (currently ill-defined, but widely used) terminology.  It describes "scanning" rather what the effects of "scanning" would look like; it describes "not allowing pattern inference" but remains open to someone redefining what "inference" means, as opposed to leveraging "indistinguishability" for a concrete definition. 

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. draft-knodel-e2ee-definition-00 is much broader could certainly be expanded to include more precise definitions to illustrate the more abstract notions. 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.
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. Given the complexity of the subject, the answer cannot always be binary.

When you say “ill-defined, but widely used terminology”, what exactly are you referring to? Statements in the press? What exact problem needs fixing here? Having a bit more context on that would certainly help with the overall assessment. Maybe we are just talking past each other.

> 
> There is a lot of overlap, but in the end https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5 <https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5> leaves the applied definition of E2E-Encryption somewhat open, whereas draft-muffett-end-to-end-secure-messaging-00 is essentially a long and nitpicky way of saying "If you're gonna call something end-to-end secure, here is what 'end' means, and you will need to respect your ends."
> 
> Obviously with enough discussion and rewriting it would be possible to somewhat merge the two documents, but since they take separate routes towards addressing the matter, I am inclined to see both go forward and see how their utility compares.
> 
>  
> You previously mentioned that intent is hard to measure and I agree with that. But I’m quite convinced a design or implementation flaw shouldn’t be called a “backdoor” until there is sufficient proof of intent. If you call it a “backdoor” right from the beginning, most people will assume that intent was there.
> This would be very discouraging for everyone who contributes to E2EE protocols, because it introduces the risk of being stigmatised as someone with (criminal) intent just because an honest mistake was made. Long story short, I strongly reject that notion of a “backdoor” for being intimidating.
> 
> 
> I hear that you are worried about pejorative stigma of terminology, so let me share the rationale that I've just added to the draft:
> 
> In software engineering there is a perpetual tension between the concepts of "feature" versus "bug" - and occasionally "misfeature" versus "misbug". These tensions arise from the problem of [DualUse] - that it is not feasible to firmly and completely ascribe "intention" to any hardware or software mechanism.
> The information security community have experienced a historical spectrum of mechanisms which have assisted non-participant access to PCASM. These have variously been named as "export-grade key restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and Meltdown), "law enforcement access fields" (Clipper), and "key escrow" (Crypto Wars).
> All of these terms combine an "access facilitation mechanism" with an "intention or opportunity" - and for all of them an access facilitation mechanism is first REQUIRED.
> An access facilitation mechanism is a "door", and is inherently [DualUse]. Because the goal of E2ESM is to limit access to PCASM exclusively to a defined set of participants, then the intended means of access is clearly the "front door"; and any other access mechanism is a "back door".
> If the term "back door" is considered innately pejorative, alternative, uncertain constructions such as "illegitimate access feature", "potentially intentional data-access weakness", "legally-obligated exceptional access mechanism", or any other phrase, all MUST combine both notions of an access mechanism (e.g. "door") and a definite or suspected intention (e.g. "legal obligation").
> So the phrase "back door" is brief, clear, and widely understood to mean "a secondary means of access". In the above definition we already allow for the term to be prefixed with "intentional" or "unintentional".
> Thus it seems appropriate to use this term in this context, not least because it is also not far removed from the similar and established term "side channel".
>  
> ...and to call out that last point, I find it particularly interesting to compare "back door" to "side channel"; to me, neither are particularly stigmatic until combined with an adjective to describe "intent".
> 

Whoever built the back door to your house hopefully did so with full intent :) This is precisely where I see the problem: doors are mechanisms built with full intent to enter a building/room. If the building/room can also be entered because the walls were not made thick enough (intentionally or unintentionally), we wouldn’t call this a door. So only when there is a strong suspicion of intent (preferably evidence), something should be called a door. I simply cannot convince myself that a door can be something that is built unintentionally. Hence the risk of stigma.
But maybe I just have an unusual understanding of what a door is. I would love to hear other opinions on this.

Raphael

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

---

From: Alec Muffett <[email-masked]>
Date: Fri, 7 May 2021 17:22:57 +0100

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 <[email-masked]> 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?

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.

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.

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

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

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

---

From: Raphael Robert <[email-masked]>
Date: Fri, 7 May 2021 22:43:39 +0200

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 <[email-masked]> wrote:
> 
> Heya!
> 
> 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>
> 
> On Fri, 7 May 2021 at 15:50, Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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".  
> 
> 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 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.
> 

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.

> 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,
> 
> 
> 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
> 
> --

---

From: Alec Muffett <[email-masked]>
Date: Fri, 7 May 2021 22:38:59 +0100

> 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

---

From: Alec Muffett <[email-masked]>
Date: Sat, 8 May 2021 12:12:33 +0100

Status Update for Functional Definition of End-to-End Secure Messaging:

1/ Version-00 has been submitted, and Version-01 started; work in progress
text and diffs are at:

URL:
https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging (see
main page for links)

2/ A big part of the reason for having a standard for measuring End-to-End
Secure Messengers is that it permits the development of objective product
comparisons; work in progress for comments, input, and corrections at:

URL:
https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyEJHRUZyqQ/edit?usp=sharing

  - Alec

---

From: Raphael Robert <[email-masked]>
Date: Sat, 8 May 2021 15:27:12 +0200

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

Whether users should really see a notification whenever someone adds a new device to their account is indeed a matter of debate. If cryptographic assurances exist that adding a new device could only have been done by possessing some private key material, I believe this nuance is indeed out-of-scope for your draft.

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

Again, the absence of examples doesn’t validate the claim. But I think there is a great example nonetheless: the re-encryption vulnerability in WhatsApp that was discovered in 2017.

I think there are lessons to be learned from that:

 - The vulnerability itself was not something that most people had on their radar before it was discovered. It was a "new” kind of vulnerability that most people hadn’t thought of. My point here is that you cannot always think of all the vulnerabilities in advance and thus produce a false negative when benchmarking.

 - The vulnerability clearly offered a way to access at least one message from a WhatsApp user (in its entirety). According to your definition of what a backdoor is (in section 4.4 in -01.), this would qualify as a backdoor. WhatsApp itself refuted the claim that this was a backdoor and so did a number news outlets (e.g. https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages <https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages>). My point here is that the definition of backdoor might still be problematic in more than one way.

 - The vulnerability was in fact a lack of authentication. My point here is that authentication really matters for E2ESM, encryption alone is not enough.

 - End user expectations were not really met and people were taken by surprise. I think was mostly due to the lack of understanding how WhatsApp works internally. My point here is that a system should only be called E2ESM when there is sufficient understanding of how it works. I’m tempted to make a concrete proposal to maybe quantify this better:

Whether a system qualifies as E2ESM can only be determined if at least 2 of the following 3 criteria are met:

 - The software has extensive documentation about its inner workings that cover all aspects that are relevant to security & privacy
 - The software is open source
 - The source code has been audited by a sufficiently independent party and the unabridged report is publicly available

> 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?

I was more thinking about the authentication on a cryptographic level between “ends”. The user-level identifier is a whole other dimension (and probably out-of-scope).
As mentioned above, authentication really matters in the context of E2ESM and the maturity of the concepts that are currently implemented in secure messengers is far behind the quality of the actual E2E encryption in itself.

> 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.
> 
> Indeed, I think that you and I last met at a MLS shindig hosted at Facebook some years ago :-)

I believe we did! :)
 
> 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.
> It is really interesting, and I am grateful for the pushback and the opportunity / spark to explain. :-)

I feel I should re-iterate that I’m not pushing back on the effort itself, I think its really commendable! 

Raphael

---

From: Alec Muffett <[email-masked]>
Date: Sat, 8 May 2021 20:26:47 +0100

On Sat, 8 May 2021 at 14:27, Raphael Robert <[email-masked]> wrote:

>
> Whether users should really see a notification whenever someone adds a new
> device to their account is indeed a matter of debate. If cryptographic
> assurances exist that adding a new device could only have been done by
> possessing some private key material, I believe this nuance is indeed
> out-of-scope for your draft.
>

Exactly.  I believe that the feature *is* however necessary for
participants to maintain integrity, because there is little benefit in
requiring group conversations to be closed against "participant injection"
(section 3.4) if the security services of an illiberal state will simply
demand (e.g. a hypothetical) that they be provided "Ghost" access via
WhatsAppForWeb, i.e. the ghost is injected into a participant instead of a
conversation.  This is why section 3.5 exists.

URL:

Again, the absence of examples doesn’t validate the claim. But I think
> there is a great example nonetheless: the re-encryption vulnerability in
> WhatsApp that was discovered in 2017.
>
>  - The vulnerability itself was not something that most people had on
> their radar before it was discovered. It was a "new” kind of vulnerability
> that most people hadn’t thought of. My point here is that you cannot always
> think of all the vulnerabilities in advance and thus produce a false
> negative when benchmarking.
>
>  - The vulnerability clearly offered a way to access at least one message
> from a WhatsApp user (in its entirety). According to your definition of
> what a backdoor is (in section 4.4 in -01.), this would qualify as a
> backdoor.
>

The WhatsApp "resend" issue does not qualify as a "backdoor" under this
specification, but you're not the first person to raise that observation.

If we quote Section 4.4:

> Backdoor: A "backdoor" is any intentional or unintentional mechanism, in
respect of a given message and that message's set of participants, where
some PCASM of that message MAY become available to a non- participant
without the intentional action of a participant.

We must also quote Section 4.1:

> Participant: A participant is any entity - human, machine, software bot,
conversation archiver, or other, that is bounded by the extent of that
entity's [TrustedComputingBase].

In the case of the WhatsApp resending "backdoor", each individual message
is legitimately encrypted to key material associated with the participant.
As we all opined at the time, this is a possibly unwise but legitimate
implementational choice: https://technosociology.org/?page_id=1687

To leverage this mechanism a malicious actor needs to steal your phone/SIM,
or clone your phone, both of which are initial failures of the Trusted
Compute Base (TCB, Section 4.1) and are outside the scope of this standard.
Otherwise it would also be necessary to accept that the "ability to steal a
Facebook account password" is likewise a backdoor in
FBMSecretConversations; or that "a malicious WhatsApp employee could "nuke"
a user's identity and - in concert with phone-cloning - re-register that
phone number to a new device owned by the malicious employee" is also
somehow a "backdoor".

At some point all "security" comes down to "standing on a bunch of
assumptions", and this standard uses the well-documented concept of a TCB
to express that point.

> WhatsApp itself refuted the claim that this was a backdoor and so did a
> number news outlets (e.g.
> https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages).
>
>

I know; I think I was the first to shout about it. Certainly I was the
rudest:
https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-1791158247
(first
paragraph)

My point here is that the definition of backdoor might still be problematic
> in more than one way.

I look forward to learning the problems and addressing them.

>  - The vulnerability was in fact a lack of authentication. My point here
> is that authentication really matters for E2ESM, encryption alone is not
> enough.
>

...and yet not all messengers require PIN-locks, instead trusting integrity
to using phone numbers as the identity principal.  Some E2ESM like Ricochet
(and, I think, Briar?) use bearer-cryptokeys simultaneously as identity
principals and network addresses, so the concept of "identity" is moot.

In short: the matter of "identity" is not obligated to extend beyond the
consistent and defined concept of an "end" / participant.  As such, it
falls out of scope.

That said, I am wondering whether it would be useful to add a wishlist of
RFC2119 "optional" features, like optional PIN-lockdown for identity, where
the platform would benefit from it. Maybe this could be one such?

 - End user expectations were not really met and people were taken by
> surprise. I think was mostly due to the lack of understanding how WhatsApp
> works internally. My point here is that a system should only be called
> E2ESM when there is sufficient understanding of how it works.
>

...and this standard literally proposes a yardstick to hold up against that
understanding.

> I’m tempted to make a concrete proposal to maybe quantify this better:
>  - The software has extensive documentation about its inner workings that
> cover all aspects that are relevant to security & privacy
>  - The source code has been audited by a sufficiently independent party
> and the unabridged report is publicly available
>

Those are all political and social requirements, which are nice and I would
welcome more software delivering them, but would exclude (say) WhatsApp
from the list.

I feel that *that* would be controversial.

> I was more thinking about the authentication on a cryptographic level
> between “ends”. The user-level identifier is a whole other dimension (and
> probably out-of-scope).
>

So, notification regarding surprise key changes, that sort of thing,
perhaps as an addition to Section 3.2?

> I think its really commendable!

Thank you! I hope some value comes out of it, including this
work-in-progress:
https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyEJHRUZyqQ/edit?usp=sharing

  - Alec

---

From: Alec Muffett <[email-masked]>
Date: Sat, 8 May 2021 22:09:50 +0100

On Sat, 8 May 2021 at 20:26, Alec Muffett <[email-masked]> wrote:

> To leverage this mechanism a malicious actor needs to steal your
> phone/SIM, or clone your phone, both of which are initial failures of the
> Trusted Compute Base (TCB, Section 4.1) and are outside the scope of this
> standard. [...deletia...].
>

Incidentally, there's a great pun / potential vulnerability name inherent
in this observation, viz: *"split ends attack"*.

Just wanted to call dibs. :-)

Have a great weekend!

    - alec

---

From: Raphael Robert <[email-masked]>
Date: Sun, 9 May 2021 19:58:45 +0200

> The WhatsApp "resend" issue does not qualify as a "backdoor" under this specification, but you're not the first person to raise that observation.  
> 
> If we quote Section 4.4: 
> 
> > Backdoor: A "backdoor" is any intentional or unintentional mechanism, in respect of a given message and that message's set of participants, where some PCASM of that message MAY become available to a non- participant without the intentional action of a participant.
> 
> > Participant: A participant is any entity - human, machine, software bot, conversation archiver, or other, that is bounded by the extent of that entity's [TrustedComputingBase]. 
> 
> In the case of the WhatsApp resending "backdoor", each individual message is legitimately encrypted to key material associated with the participant.  As we all opined at the time, this is a possibly unwise but legitimate implementational choice: https://technosociology.org/?page_id=1687 <https://technosociology.org/?page_id=1687>
> 
> To leverage this mechanism a malicious actor needs to steal your phone/SIM, or clone your phone, both of which are initial failures of the Trusted Compute Base (TCB, Section 4.1) and are outside the scope of this standard. Otherwise it would also be necessary to accept that the "ability to steal a Facebook account password" is likewise a backdoor in FBMSecretConversations; or that "a malicious WhatsApp employee could "nuke" a user's identity and - in concert with phone-cloning - re-register that phone number to a new device owned by the malicious employee" is also somehow a "backdoor".
> 
> At some point all "security" comes down to "standing on a bunch of assumptions", and this standard uses the well-documented concept of a TCB to express that point.
> 
>  
> WhatsApp itself refuted the claim that this was a backdoor and so did a number news outlets (e.g. https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages <https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature-encrypted-messages>).
> 
> I know; I think I was the first to shout about it. Certainly I was the rudest: https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-1791158247 <https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-1791158247> (first paragraph) 

Yeah, that’s not how I remember it. I’m pretty sure the gist of it was that the vendor (or an actor controlling the vendor’s infrastructure) could convince WA clients to re-encrypt messages to a different cryptographic identity. No SIM-card cloning was required.
I’m absolutely not calling this a backdoor, but it was a way for the vendor to stealthy trigger re-encryption and thus potentially get access to message content. There’s a good chance that falls under your new definition of a backdoor.
I find the section 4.2 & 4.5 in draft-knodel-e2ee-definition-01 less controversial in that respect and they are probably sharp enough to serve as a yardstick.

> ...and yet not all messengers require PIN-locks, instead trusting integrity to using phone numbers as the identity principal.  Some E2ESM like Ricochet (and, I think, Briar?) use bearer-cryptokeys simultaneously as identity principals and network addresses, so the concept of "identity" is moot. 
> 
> In short: the matter of "identity" is not obligated to extend beyond the consistent and defined concept of an "end" / participant.  As such, it falls out of scope.
> 
> That said, I am wondering whether it would be useful to add a wishlist of RFC2119 "optional" features, like optional PIN-lockdown for identity, where the platform would benefit from it. Maybe this could be one such?

Agreed, I really wouldn’t consider anything beyond the cryptographic identity of an endpoint. Anything else is vendor-specific as you say.

> Those are all political and social requirements, which are nice and I would welcome more software delivering them, but would exclude (say) WhatsApp from the list.  
> 

Oh well, I see that differently. If rubber-stamping some of FB’s poorer decisions with that draft is a desired goal, it changes the optics quite a bit. 
draft-knodel-e2ee-definition-01 has a much higher degree of independence.

> So, notification regarding surprise key changes, that sort of thing, perhaps as an addition to Section 3.2?

It really falls in under “authentication” in general. draft-knodel-e2ee-definition-01 has the nice concept of encrypted channels (although it contradicts the MLS notion of groups a bit).
It should be clear to the user at the time of encryption who the participants are and there should be a way to verify the participants and their cryptographic identity. I know this pretty much excludes iMessage. But if we want a definition of E2ESM that covers iMessage, we need to drop authentication completely and that’s definitely weak sauce.

Raphael

---

From: Sofía Celi <[email-masked]>
Date: Mon, 10 May 2021 00:41:30 +0100

Dear, Raphael,

Thank you so much you all for this very interesting thread.

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

These are really interesting points. I see four points:

* Future or past recipients of a conversation: it could be that a
conversation is read prior to the intended recipient, or after the
intended recipient. This is somewhat not cover in every day
applications, as someone else can get access to a device and read the
messages intended for a recipient. In those terms, I think this is
described as 'secure' for the network (and the intended recipient is the
device, then); but if a device is compromised, then the contents could
be potentially read by someone else. A point to include here then is the
idea of 'disappearing messages', as a property for trying to avoid this.
But if a message is read and disappeared prior to the actual "recipient"
reading it, then the purpose is also lost. It could also be that someone
asks you to show the contents of a conversation, as it has happened to
many while crossing borders or an abusers that controls the devices in a
case of domestic violence.
* Messages read by something that is not a "human": this could be a bot
that is part of a conversation (but should it be?, if so, it should be
disclosed to the sender-s-, and potentially properly "authenticated") or
malware in the device itself.
* Messages read by a backdoor or vulnerability: I think that if an
application has a backdoor (with the whole purpose of having it there to
read the contents) then it is not end-to-end encrypted. If someone or
something is added to the conversation, then it should be authenticated
and disclosed.
* Multiple devices: this could be better explained by stating that the
intended recipients could be multiple devices (these all have to be
authenticated to the conversation).

I really like all of these points (for taking them into account).
@Mallory, I can add some ideas around this to our draft and we can
discuss all further ;)

Thank you,

-- 
Sofía Celi
@claucece
http://claucece.github.io/
Cryptographic research and implementation at many places, but mainly at
Cloudflare
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 May 2021 07:30:31 +0100

On Sun, 9 May 2021 at 18:58, Raphael Robert <[email-masked]> wrote:

> Yeah, that’s not how I remember it. I’m pretty sure the gist of it was
> that the vendor (or an actor controlling the vendor’s infrastructure) could
> convince WA clients to re-encrypt messages to a different cryptographic
> identity. No SIM-card cloning was required.
>

Mm; there's a very simple proof of my point: in order to add a new device
and to steal these messages, it is first necessary for the malicious actor
to successfully impersonate a new user device, in order to subvert the
trust that WhatsApp has in the integrity of the user.

To perform this subversion requires SIM-cloning, some form of
phone-jacking, or - in the very simplest circumstance, as happened to one
of my family last week - socially engineering the user to forward the
confirmatory SMS/nonce for new device setup, *to* the malicious actor.

The proof is: this is an abnormal activity. It mostly does not happen,
otherwise far more WhatsApp account theft would occur, enabled by malicious
actors simply connecting a new device and saying "Hey, I am Raphael Robert,
please send me anything addressed to him."

*This* is the concept of a Trusted Compute Base.

We should all be deeply worried that the integrity of Signal, WhatsApp,
etc, all rely upon confirmatory SMSes, but that's outside the scope of this
standard.

> Agreed, I really wouldn’t consider anything beyond the cryptographic
> identity of an endpoint. Anything else is vendor-specific as you say.
>

Concur.

> If rubber-stamping some of FB’s poorer decisions with that draft is a
> desired goal, it changes the optics quite a bit.

That's a tragic strawman; to repeat, the goal is to provide a metric for
judging the "minimally viable product behaviour" for something to be worthy
of being called "end-to-end secure"; it's also short, and measurable
against an implementation.

> It really falls in under “authentication” in
> general. draft-knodel-e2ee-definition-01 has the nice concept of encrypted
> channels (although it contradicts the MLS notion of groups a bit).
> It should be clear to the user at the time of encryption who the
> participants are
>

For me, that's Sections 3.1 and 3.2.

> and there should be a way to verify the participants and their
> cryptographic identity.
>

Yes, but "verify them against... what?" [explanation follows below, after
joke]

> I know this pretty much excludes iMessage. But if we want a definition of
> E2ESM that covers iMessage,
>

Rubber-stamping some of Apple's decisions? [joke]

> we need to drop authentication completely and that’s definitely weak sauce.
>

The word "authentication" is only meaningful within two - what shall we
call them, "frames"?

1/ that the "participant" is-or-is-not part of the conversation; but that's
the very *definition* of an end-to-end-secure conversation: that "the only
people who can read are participants, and participants are those who can
read", and it is the trusted-compute-base of each participant-entity which
defines their participation

2/ that the "participant" somehow relates to some external identity
framework, for instance a PKI or a Driving License Number.

...however I suspect that you may mean:

3/ that the "participant" is fully in control of their devices and
endpoints, and that one of them has not been subverted or inserted by a
malicious actor; but this (again) eventually requires the E2ESM client to
perform a security audit of the device that it's hosted on, etc.  This one
is hard, and possibly illiberal/unwise.

I would like to check please whether I am correctly reflecting your wants
for authentication? 1, 2, 3, or other?

    - Alec

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 May 2021 08:14:31 +0100

Hi Sofía!

On Mon, 10 May 2021 at 00:41, Sofía Celi <[email-masked]> wrote:

> be potentially read by someone else.

Exactly.  This is the concept of the Trusted Computing Base, in a nutshell:
https://en.wikipedia.org/wiki/Trusted_computing_base

> A point to include here then is the

They are very useful - I am a strong convert to them, although they are not
obligatory for an end-to-end secure messaging network.

> reading it, then the purpose is also lost.

Yes; or alternatively if they exist until "N" hours or days after being
read on any given device, there are other models where their purpose is
also lost.

On that basis, it's up to the user to make wise choices and use of the
features that exist *beyond* basic end-to-end security.

> malware in the device itself.

If a "Bot" should be disclosed to a sender, should it also be disclosed
that the user is using an assistive spellchecker app?

Or an assistive keyboard app which may exfiltrate content to Chinese state
authorities?

Example of this latter debate:
https://www.reddit.com/r/privacytoolsIO/comments/kzpxwt/opinions_on_naomi_wu_signal_ime_vulnerability/

Hence why I believe that it is not tenable to pursue disclosures of
anything beyond "these are the participants within this conversation, and
the rest of the universe is outside".

Or perhaps those "assistive apps" exist as backdoors, in which case:

> read the contents) then it is not end-to-end encrypted.

...does this mean that anyone with a spellchecker (Grammarly:
https://www.silicon.co.uk/security/grammar-extension-data-leak-flaw-228005)
or chinese keyboard, is excluded from what being we would call "end-to-end
secure"?

The only resolution for this that I can see - that is even possible? - is
for the participant to define their "trusted computing base".  Hence this
draft standard.

> If someone or

Strongly concur.

> authenticated to the conversation).

What if one device has several heads, such as "WhatsAppForWeb"?  Should
those be disclosed?

Should a victim of domestic abuse attempting to escape - or: a philanderer
- be "outed" as having a second phone?  As using a secret laptop?

     - alec

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 10 May 2021 09:45:27 -0400

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.
>
>> All references in the attached, are against:�
>>
>> URL: 
>>     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". �
>>
>> /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.
>>
>>
>> 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.
>>
>> �
>>
>>     simplicity but might simply prove to be insufficient to capture
>>     all valid use cases.
>>
>>
> 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, 
>>     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.
>>
>>
> 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.
>
>> �
> 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).
>
>> �
>>
>> "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*,
>>
>>
>> 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.
>>
>> '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.
>
>>     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
>>
>> -- 
> _______________________________________________
> MLS mailing list
> [email-masked]

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

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 May 2021 15:46:08 +0100

On Mon, 10 May 2021 at 14:45, Mallory Knodel <[email-masked]> wrote:

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

Hey Mallory!

I would be delighted to help your effort, too - but to do that I would need
to better understand what the intention or threat model is - what it is
meant to be "strong" against?

My work is focused upon building a metric which can be used to measure any
communications service which claims to offer end-to-end security, whether
or not the service uses content encryption or alternately strong direct
peer-to-peer transport encryption. My goal is to hold yardstricks up
against applications and services and provide a "yes/no" regarding whether
the service is end-to-end secure; and also to speak to whether a
proposed government intervention would cause it to no longer be "end-to-end
secure".

I've been working on this blindly, but having finally circulated this draft
I am pleased to learn that the concepts line up quite well with a 2011
paper from David Clark & Marjory Blumenthal:

*"The End-to-End Argument and Application Design: The Role of Trust":*
https://www.repository.law.indiana.edu/cgi/viewcontent.cgi?article=1585&context=fclj

...and also an earlier (and less relevant) work by the same:

*"Rethinking the design of the Internet: The end to end arguments vs. the
brave new world"*
https://cyberlaw.stanford.edu/e2e/papers/TPRC-Clark-Blumenthal.pdf

Quoting the former:

*The original paper provides a hint as to the importance of this
distinction. Using a telephone call as an example, it points out that the
ultimate end points are not the computers, but the humans they serve.8 As
an illustration of human-level end-to-end error recovery, one person might
say to another: "[E]xcuse me, someone dropped a glass. Would you please say
that again?"9 The humans are the prime movers in the activity, the ultimate
end points. The computers are just their agents in carrying out this
objective.*

...and...

*There is an explicit assumption in the original paper that the
communications subsystem is unreliable.'3 This assumption is justified
(both then and now) for the reasons listed above. But there is an implicit
assumption that the end node is reliable and trustworthy. The example of
"careful file transfer" in the original paper 4 assumes that the end node
can compute a checksum reliably and perform other actions designed to
compensate for the unreliability of the communications. It also assumes,
implicitly, that the two ends trust each other. *

...and...

*The function in question can completely and correctly be implemented only
with the knowledge and help of the application standing at apoint where it
can be trusted to do its job in a reliable and trustworthy fashion. Trust,
in this context, should be determined by the ultimate end points-the
principals that use the application to fulfill their purposes. Because the
locus of trust is naturally at the ends, where the various principals are
found, "trust-to-trust" is preferable to "end-to-end" from the point of
view of the principals, because it more directly invites the important
question of "trusted by whom?" That question, in turn, relates to questions
that implicate application design, notably "who gets to choose which
service is used?" or "which parts of an application are in which service
modules?" Answers to these questions illuminate who controls what aspects
of an application.*

...all of which resonate extraordinarily loudly with the thinking in
my draft. Dan Geer pointed me at them this morning, and I am still inhaling
the papers excitedly.  I am particularly enamoured of the *"trust-to-trust
is preferable to end-to-end"* concept, because it so neatly encapsulates
the issues that I want to communicate and build upon: that each
{participant or end} is a little universe of self-trust, and that the
purpose of *end-to-end secure messaging* is to build a virtual, private,
tamperproof "series of tubes" between them, irrespective of implementation
technology. :-)

In comparison draft-knodel-e2ee-definition - according to the introduction
- "defines end-to-end encryption (E2EE) using three different dimensions
that together comprise a full definition of E2EE, which can be applied in a
variety of contexts", which is a different goal to my "metricate
end-to-end"; I am reading it as a sequence of features, definitions and
user-expectations, but am not yet seeing what is meant to happen when those
expectations are broken, and I don't know if you're interested in seeing
that suggested and/or against whom that sanction will need to stand?

    - Alec

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 10 May 2021 12:01:33 -0400

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

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

---

From: Raphael Robert <[email-masked]>
Date: Mon, 10 May 2021 21:50:41 +0200

> On 10. May 2021, at 08:30, Alec Muffett <[email-masked]> wrote:
> 
> 
> 
> On Sun, 9 May 2021 at 18:58, Raphael Robert <[email-masked] <mailto:[email-masked]>> wrote:
> Mm; there's a very simple proof of my point: in order to add a new device and to steal these messages, it is first necessary for the malicious actor to successfully impersonate a new user device, in order to subvert the trust that WhatsApp has in the integrity of the user.
> 
> To perform this subversion requires SIM-cloning, some form of phone-jacking, or - in the very simplest circumstance, as happened to one of my family last week - socially engineering the user to forward the confirmatory SMS/nonce for new device setup, *to* the malicious actor.
> 
> The proof is: this is an abnormal activity. It mostly does not happen, otherwise far more WhatsApp account theft would occur, enabled by malicious actors simply connecting a new device and saying "Hey, I am Raphael Robert, please send me anything addressed to him."
> 

I think we need to dial back a bit here. TCB works like a framework, which means it needs a security policy that is clearly defined (Wikipedia article: "the boundaries of the TCB depend closely upon the specifics of how the security policy is fleshed out.”). I don’t see that in the draft yet, except for some provisions in 5.

From your answer it looks like you exclude the vendor as a threat actor, which strikes me as odd since the very essence of E2EE is to protect users against attacks where the vendor is a threat actor.
But I don’t want to jump to conclusions, I’ll wait for a more clearly defined security policy first.

> If rubber-stamping some of FB’s poorer decisions with that draft is a desired goal, it changes the optics quite a bit. 
> That's a tragic strawman; to repeat, the goal is to provide a metric for judging the "minimally viable product behaviour" for something to be worthy of being called "end-to-end secure"; it's also short, and measurable against an implementation.
> 
> 
> It should be clear to the user at the time of encryption who the participants are
> 
> and there should be a way to verify the participants and their cryptographic identity.
> 
> Yes, but "verify them against... what?" [explanation follows below, after joke]
>  
> I know this pretty much excludes iMessage. But if we want a definition of E2ESM that covers iMessage,
> 
> The word "authentication" is only meaningful within two - what shall we call them, "frames"?
> 
> 1/ that the "participant" is-or-is-not part of the conversation; but that's the very *definition* of an end-to-end-secure conversation: that "the only people who can read are participants, and participants are those who can read", and it is the trusted-compute-base of each participant-entity which defines their participation
> 
> 2/ that the "participant" somehow relates to some external identity framework, for instance a PKI or a Driving License Number.
> 
> 3/ that the "participant" is fully in control of their devices and endpoints, and that one of them has not been subverted or inserted by a malicious actor; but this (again) eventually requires the E2ESM client to perform a security audit of the device that it's hosted on, etc.  This one is hard, and possibly illiberal/unwise.
> 
> I would like to check please whether I am correctly reflecting your wants for authentication? 1, 2, 3, or other?

If anything, it would be closest to 2. In all usual protocols like PGP, MLS, OTR, Signal, TLS, Wireguard, etc. the endpoints have a public identity key. Whether this key is part of a larger PKI or is otherwise associated with another identifier (e.g. a phone number) is very vendor specific and should be out-of-scope. But the key itself should be part of the system. In more abstract terms, the key is referred to as a “cryptographic identity”. This is the base layer of E2E authentication.
How exactly the key is verified is again vendor specific. The important part is that the key can be verified and that you don’t have to blindly trust the vendor.

Raphael

---

From: Alec Muffett <[email-masked]>
Date: Mon, 10 May 2021 21:48:44 +0100

On Mon, 10 May 2021 at 20:50, Raphael Robert <[email-masked]> wrote:

> I think we need to dial back a bit here. TCB works like a framework, which
> means it needs a security policy that is clearly defined (Wikipedia
> article: "the boundaries of the TCB depend closely upon the specifics of
> how the security policy is fleshed out.”). I don’t see that in the draft
> yet, except for some provisions in 5.
>

Correct.  It's not possible for an app to tell a user what their security
policy can or should be.

That would be like the tail wagging the dog.

The user has (whether they realise it or not) a security policy and threat
model.  They trust some devices, some services, not others.  They choose to
use an app and to trust it.  They add it to their TCB.

Who are we to tell them that they have everything wrong?

>
> From your answer it looks like you exclude the vendor as a threat actor,
> which strikes me as odd since the very essence of E2EE is to protect users
> against attacks where the vendor is a threat actor.
>

Again, I frame it this way: the user chooses to trust a vendor.  That's how
TCBs and users work.

> defined security policy first.

It's not up to me to deliver one - although to be fair, one can see *hints*
of this in (say) Signal, where it attempts to block itself from being run
on "rooted" Android systems; however one can't put stuff like that into a
communications standard.  It belongs instead in an "application value
proposition".  It's part of Signal's sales pitch.

> 1/ that the "participant" is-or-is-not part of the conversation; but
> that's the very *definition* of an end-to-end-secure conversation: that
> "the only people who can read are participants, and participants are those
> who can read", and it is the trusted-compute-base of each
> participant-entity which defines their participation
>
> If anything, it would be closest to 2.
>

Wow.  You want to tie communications to real-life identities?

> In all usual protocols like PGP, MLS, OTR, Signal, TLS, Wireguard, etc.
> the endpoints have a public identity key. Whether this key is part of a
> larger PKI or is otherwise associated with another identifier (e.g. a phone
> number) is very vendor specific and should be out-of-scope. But the key
> itself should be part of the system. In more abstract terms, the key is
> referred to as a “cryptographic identity”. This is the base layer of E2E
> authentication.
>

Oh, okay, so maybe you don't want to tie communications to real-life
identities, you're just saying that there's one principal-key-or-identity
per participant?  That would be fine, but then...

How exactly the key is verified is again vendor specific.
The important part is that the key can be verified and that you don’t have
> to blindly trust the vendor.
>

Okay, so what you're asking for is that an E2ESM must surface some
individual or joint identity token with which Alice can prove herself to
Bob, out of band, to assure trust?

That seems reasonable, but in some cases redundant - like, for instance,
Ricochet, where in order for Bob to communicate at all with Alice, he must
already have her Onion Address.  There's no other cryptography involved,
and the Onion Address is also a network endpoint.

There would be no other token, but then there would also be no intermediary
"vendor". This sounds good.

However: anyone who follows / is aware of Darkweb markets will also know
that they are regularly faked. The Onion Address - or indeed any static
per-client "identity key" for any participant - can and will be spoofed by
AliceFake1, AliceFake2 (etc) - so long as the Fake Alices do a good job of
social-engineering themselves into public awareness.

So such keys are a nice-to-have and will add a little extra assurance, but
I don't see mandating this as achieving anything other than an "extra layer
of indirection"?  The additional trust they provide is not quantifiable?

If it is, how is it measured?

    - alec

---

From: Alec Muffett <[email-masked]>
Date: Tue, 11 May 2021 07:11:19 +0100

On Mon, 10 May 2021 at 17:01, Mallory Knodel <[email-masked]> 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!

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

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

> 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