Re: End-to-end Encrypted Messaging in ActivityPub

Evan,
While redirecting to an out-of-band service would address the need for
private DMs, it would leave other uses of cryptography unaddressed. I'm
working on a set of needs that require message-integrity and signatures.
Unfortunately, many of the same key management, and other issues that make
encryption hard also exist for signatures. So, I've been hoping that a
solution to encryption would make it more obvious how to do signing.

bob wyman


On Tue, May 23, 2023 at 2:44 PM Evan Prodromou <evan@prodromou.name> wrote:

> So, a couple of thoughts.
>
> First, I think the option for using other chat services is great.
>
> One pattern is that users of e.g. Mastodon could add their e.g. Signal
> account information in their user settings, and other users could discover
> that information either as a Webfinger property, or as a property of the
> Actor object. They could then initiate a conversation out of band, and the
> conversation would be managed with a different client.
>
> Second, the in-band option doesn't have to be incompatible with this. They
> could be complementary.
>
> Evan
>
>
>
> On May 23, 2023 14:07, Johannes Ernst <johannes.ernst@gmail.com> wrote:
>
> 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
>
>
> 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> 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> 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.)
>
>
>
>