The important thing is: I (soatok@furry.engineer) should be able to query pawb.fun, find the Directory Server(s) they federate with, and then query that Directory server for Crashdoom@pawb.fun and get his currently trusted Ed25519 public keys.
I don’t understand how this gives you any trust that the key you got was actually created by the user who has the account Crashdoom@pawb.fun. All you know is that a directory server has the key in a message it claims came from that user. Where’s the proof?
Additionally, all messages defined here are generated by the users, client-side. Servers are not trusted, generally, as part of the overall E2EE threat model.
and
The first AddKey for any given identity will need to be self-signed by the key being added (in addition to ActivityPub messages being signed by the instance).
After an identity exists in the directory, every subsequent public key MUST be signed by a non-revoked keypair.
So, it is sufficient to verify that:
The user you want to talk to owns the key in the original AddKey message (hard)
The signatures for subsequent AddKey operations follow spec (trivial)
#1 kind of reduces to how we can know anything at all about anybody online. Presumably the user’s profile (on a different instance than the keyserver) would have some field displaying their public key (this doesn’t require any modification, mastodon profiles include four “extra fields” with arbitrary labeled text), but then of course you must trust that user’s instance. The threat model here I guess is that the user’s instance is squatting their username/key mapping to MITM any communication that is sent to them. This is possible but it’s also easily detectable, and also becomes part of the same kind of uncertainty about whether the profile corresponds to the real-world person you want to communicate with (if you even know or care about that aspect of them).
Bingo. People have flamed me for saying this, but I have more trust in Apple, or even Meta, than I do in some rando who runs a Mastodon server. There’s just so much more public accountability, as well as professionalism in their data security.
#1 kind of reduces to how we can know anything at all about anybody online
Right, which was the thing I kept waiting to hear addressed during the entire post.
With federation, you’ve still outsourced your identity to a 3rd party whom you have no choice but to trust. The only difference is there are many such third parties; which does have some benefits, but also drawbacks, and overall I don’t think the big increase in complexity is worth it. It’s an unsatisfying middle ground between monolithic services and true distributed identity.
💯 I love federation but I love it because I can run my own service and I love it because in an ideal world I can choose which of the major players I want to use without losing anything. I don’t want to host myself on some random server run by a volunteer who will burn out or get bored.
~cks has an interesting response to this article, regarding account recovery
I don’t understand how this gives you any trust that the key you got was actually created by the user who has the account Crashdoom@pawb.fun. All you know is that a directory server has the key in a message it claims came from that user. Where’s the proof?
This seems to reduce to this:
and
So, it is sufficient to verify that:
#1 kind of reduces to how we can know anything at all about anybody online. Presumably the user’s profile (on a different instance than the keyserver) would have some field displaying their public key (this doesn’t require any modification, mastodon profiles include four “extra fields” with arbitrary labeled text), but then of course you must trust that user’s instance. The threat model here I guess is that the user’s instance is squatting their username/key mapping to MITM any communication that is sent to them. This is possible but it’s also easily detectable, and also becomes part of the same kind of uncertainty about whether the profile corresponds to the real-world person you want to communicate with (if you even know or care about that aspect of them).
Bingo. People have flamed me for saying this, but I have more trust in Apple, or even Meta, than I do in some rando who runs a Mastodon server. There’s just so much more public accountability, as well as professionalism in their data security.
Right, which was the thing I kept waiting to hear addressed during the entire post.
With federation, you’ve still outsourced your identity to a 3rd party whom you have no choice but to trust. The only difference is there are many such third parties; which does have some benefits, but also drawbacks, and overall I don’t think the big increase in complexity is worth it. It’s an unsatisfying middle ground between monolithic services and true distributed identity.
💯 I love federation but I love it because I can run my own service and I love it because in an ideal world I can choose which of the major players I want to use without losing anything. I don’t want to host myself on some random server run by a volunteer who will burn out or get bored.
[Comment removed by author]