Re: End-to-end Encrypted Messaging in ActivityPub

We — as this group -- have three choices on e2e messaging:

1. Do nothing. I don’t think anybody advocates that, and nobody objected to working on it in the survey (there were objections to other possible work items, but not this one.)

2. Grow our own. This would likely fit most seamlessly into the the existing architecture, but is hard to get right as Bob points out.

3. Reuse something that works somewhere else, such as what Signal does or Matrix does. That would likely not fit as well into the architecture, but it’s likelier to be secure IMHO because lots of other people have already worked on it for years (Of course we could only make that judgment once there’s a detailed design.)

I propose:

* create a small sub-group of motivated, well-qualified (in security) people to go off, debate, and come back with a high-level proposal. Or maybe two if they can’t agree.

BTW, there is a question about just how secure we want this to be, and against what kind of attack. Personally I believe it should be no less than best-of-class as implemented in Signal, for example. Everything else is going to get us skewered in the court of public opinion, and we don’t want to be the people accused to steering muggles to “inferior” secure messaging if more secure messaging exists in other consumer apps.

Cheers,



Johannes.

Johannes Ernst
Blog: https://reb00ted.org/
FediForum: https://fediforum.org/
Dazzle: https://dazzle.town/

> On May 23, 2023, at 05:41, Sean O'Brien <sean.obrien@yale.edu> wrote:
> 
> It seems to me that there has been analysis paralysis around this feature and I think we're likely adding complexity where it's not necessary.
> 
> The need is clear, and has been explained many times with the use case of DMs. We can keep dismissing this, or we can start working on it (and it seems a few folks have started, giving others fertile ground to build on).
> 
> Users not only deserve but expect privacy of direct messages on platforms that offer that functionality, and folks utilize DMs specifically for conversations they would rather not be viewed by a malicious actor or breached and published publicly.
> 
> I would expect a detailed rationale to be at the start of a proposal, as the intro before the technical details, not a separate prerequisite.
> 
> Cheers,
> - Sean
> 
> 
> -- 
> Sean O'Brien
> Fellow, Information Society Project at Yale Law School
> Founder, Privacy Lab at Yale ISP, https://privacylab.yale.edu <https://privacylab.yale.edu/>
> 
> 
> On May 20, 2023 6:18:01 PM UTC, Bob Wyman <bob@wyman.us> wrote:
>> 
>> It is good that Ben reminds us that the problem of e2ee is much more difficult than most expect. Trivially, it seems that once you've got a key-pair, you can just start encrypting stuff with a few lines of code and a good library. The reality is very different and only now appreciated by a very small number of people who are deeply steeped in the obscure realms of cryptography and security. Even though I've been working, on and off, with cryptographic methods since the late 1980's (i.e. over 30 years), I've often found protocols or specs that appeared to me to be well thought out, only to later discover that someone much more expert than I has dismissed the described methods as dangerous, ineffective, or whatever. 
>> 
>> Given that this problem is so hard, I'd like to suggest that an effort be made not only to define useful, secure methods, but also to ensure that there is a good and easily accessible explanation for why the methods were chosen over alternatives. In essence, I'm suggesting that effort be put into writing what in some OSI Standards efforts we called a standard's "rationale." Yes, I do realize that if the issues are debated on mailing lists, one can always dig through those lists to elucidate the history behind the standard's dictates, however, I think few are likely to do that work. It would be better to attempt to maintain a discipline that requires that a detailed rationale be provided before any method is incorporated into the standard. In essence, one should explain "why" before documenting the specifics of "what" or "how." 
>> 
>> bob wyman
>> 
>> 
>> 
>> On Fri, May 19, 2023 at 11:31 PM Benjamin Goering <ben@bengo.co <mailto:ben@bengo.co>> wrote:
>>> soatak also started writing about this 6 months ago, and I thought it was a great contribution. There is also a repo to contribute to:
>>> https://soatok.blog/2022/11/22/towards-end-to-end-encryption-for-direct-messages-in-the-fediverse/
>>> f
>>>> 
>>>> On May 19, 2023, at 19:21, a <a@trwnh.com <mailto:a@trwnh.com>> wrote:
>>>> 
>>>> 
>>>> > We need simple PGP-style key exchange for DMs
>>>> 
>>>> we could honestly jump straight to OMEMO-like schemes and have servers generate pre-keys for their actors. i don't think PGP-style is worth going for unless you want to be able to persistently verify authored activities after-the-fact, and don't mind (or perhaps want?) anyone with the key being able to decrypt your messages.
>>>> 
>>>> aside from that: i'm personally not convinced that we "need" such complexity. maybe it would be "nice to have" a way to do stuff like this over activitypub, but i think before encrypted messaging there needs to be a way to do plaintext messaging. until then, people will continue to go out-of-band to a dedicated messaging app.
>>>> 
>>>> my current thoughts/notes on "messaging over activitypub" are as follows:
>>>> 
>>>> - `Create Note` alone can be confused for a "status" or any of the other myriad things a `Note` gets used for. pleroma / litepub at one point in 2019 developed the ChatMessage as a new type and they sent out `Create ChatMessage`; i think this is not exactly the right approach since it makes more sense to have `Message` as an IntransitiveActivity which represents a "message" instead of a "resource". this also eliminates the need for wrapping in a `Create`. such `Message` activities could be transient if desired, or they could be persistent if given an `id`. (alternatively, if `context` was understood, you could have an explicit "messaging context" representing the room or conversation.)
>>>> 
>>>> - the other thing we'd want to heavily look into and think about is metadata encryption. if we just encrypt, sign, attest, verify, etc. the content, then that's surely simpler, but it is also surely far less useful in many cases. otherwise, we could have had `content_sig` or something similar years ago to cryptographically work with the `content` and no other properties. i am reminded somewhat of diaspora*'s approach to this, which was to have a "magic envelope" https://diaspora.github.io/diaspora_federation/federation/magicsig.html that would encode the entirety of the "message" and then sign that encoded string. we could do something similar by having some dedicated Envelope activity type serve as this "envelope" which might contain `summary` and `content` as proposed above by Evan's blog post. i haven't fully considered the exact details, but i think at minimum you would have to leak the `actor` if nothing else. (this is because of the requirement to use activities to avoid the wrap-in-Create behavior. addressing could be hidden by use of bto/bcc instead of to/cc.)