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

[Alec Muffett <[e-mail]>]

On Sun, 9 May 2021 at 18:58, Raphael Robert <[e-mail]> 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.


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

Concur.



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

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.


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



-- 
https://alecmuffett.com/about