I don't believe that's a part of the current spec (https://swicg.github.io/activitypub-e2ee/mls)

[benpate@mastodon.social]

I don't believe that's a part of the current spec (https://swicg.github.io/activitypub-e2ee/mls)

We have a very tight timeline for our first round of work, so we're focusing heavily on initial MVPs that implement the required protocols.

But, we're already talking about keys and synchronization on GitHub (https://github.com/swicg/activitypub-e2ee/issues). These will very likely be follow-on tasks after our first deliverables, and I'd love for you to help us work through these issues there.

@risottobias @bonfire @soatok

[soatok@furry.engineer]

@benpate @risottobias @bonfire Ah, I guess that means I should dust off my original draft from 2022

[benpate@mastodon.social]

Yes please. Could you post a link to what you've done so far?

@soatok @risottobias @bonfire

[soatok@furry.engineer]

@benpate @risottobias @bonfire I think you misunderstood.

I'm suggesting that the decision to not include secure public key management will tie your hands to support whatever insecure thing you're doing now for the sake of backwards compatibility, so I'm probably better off working on my own thing than trying to participate.

[soatok@furry.engineer]

@benpate @risottobias @bonfire But for posterity:

https://github.com/soatok/mastodon-e2ee-specification

I started this in 2022 and then shifted gears to Key Transparency with the intent to switch back once that problem was solved. KT slots neatly into the "Federated PKI" vacancy on the 2022 repo

[evan@cosocial.ca]

@soatok @benpate @risottobias @bonfire how about we all work together to make everything better?

[evan@cosocial.ca]

@soatok @benpate @bonfire

(Dropping Risotto Bias who got in the middle of a conversation they didn't actually want to be in)

[evan@cosocial.ca]

@soatok @benpate @bonfire

The spec that we have makes the client key packages available as a property of the ActivityPub actor. This is very convenient in the AP ecosystem, since they can be managed (created, added, removed, deleted) with the ActivityPub API. MLS grinds through key packages pretty frequently, so it's good to have this easy to do.

[evan@cosocial.ca]

@soatok @benpate @bonfire

This structure has the downside that intervening entities can insert their own key packages into the collection -- so that remote clients encrypt to all the actor's keys, as well as to the interloper's keys.

For example, if Actor A's server adds its own key to the collection, any messages sent to Actor A will also be encrypted to the server. Exactly what we are trying to avoid!

[evan@cosocial.ca]

@soatok @benpate @bonfire

There are other entities in the ecosystem that could also add keys. For example, if Actor B uses their server's proxyUri to fetch Actor A's key package collection, B's server could also add in a separate key package.

[evan@cosocial.ca]

@soatok @benpate @bonfire one way to mitigate this kind of attack is key verification. This is simply having Actor A and Actor B set up communications out of band, like on a phone call, and list out the key packages they see for each other. It's crude, and nobody ever wants to do it, but theoretically the possibility that this could happen keeps attackers from using this technique.

[evan@cosocial.ca]

@soatok @benpate @bonfire Soatok's work provides another mechanism. It is an out-of-band server that e2ee clients submit their keys to. Actor B's client can compare the keys that it gets from Actor A's server with the keys it gets from the Key Transparency server to make sure they are all listed. If it finds keys that aren't listed, it can warn the user, or just drop the key.

[soatok@furry.engineer]

@evan @benpate @bonfire Such attacks are rare to begin with, so I don't know how well their behavior maps to game theory, but if I were prone to gamble, I would bet on "they found an easier attack" sooner than "the possibility that someone might compare fingerprints is enough to dissuade the tactic". Social engineering is unreasonably effective on most people.

[evan@cosocial.ca]

@soatok @benpate @bonfire yeah. The fact that the verification UIs are often closed source clients published by the same corporation that makes the server software makes them kind of security theater. The software maker could just hide the secret server keys from the verification UI. I think it's a more robust protection in a multiplayer ecosystem, where clients and servers are written and operated by different entities.