Domains changing hands (scope of an Actor's identity?)

[puckipedia]

imagine: someone buys example.com, sets up an AP server. then, due to a mistake, they let the domain lapse and some (non-)malicious actor buys it. Can they now impersonate everyone on the server?

• Should you scope identity to id + publicKey? Does that mean that if the keypair is weak and/or leaks, that you lose your current sense of identity?
• How do other servers get to know about the changing of hands of domains?
• Some servers (e.g. Mastodon) require a unique preferredUsername plus origin combination, and if the ID changes but preferredUsername stays the same, it won't federate anymore.

[jaywink]

If all messages were signed, this would not be possible ;)

[cwebber]

If all messages were signed, this would not be possible ;)

That's not necessarily true. Consider the following:

• How do you trust that a key is associated with an actor? Well, you probably looked up the actor's id and found a key and said "okay, that's their key now". Fine.
• If the actor now puts a new key there, would you update your sense of what key belongs to that actor? Consider your choices:
  • If yes, you're vulnerable to the same attack @puckipedia described
  • If no, and you don't have an upgrade mechanism, that means your real identifier isn't your URI... it's your key fingerprint.

What happens in the last case if you need to update your keys? There are plenty of reasons for this, losing them is only one. For example, the first PGP key I ever had was a 1024 bit RSA key... fine at the time, but woefully insecure today. If your identity is "effectively your fingerprint", and we want our systems to survive more than a decade, you have to have a key upgrade mechanism.

And indeed, a key upgrade mechanism is something decentralized identifiers provide. You can say "okay, I trust these 4 people, and if 3 out of 4 say this is my new key, it's my new key". So you can have an identifier and have it be yours for life.

Signatures alone don't solve this, but they are part of the solution.

[nightpool]

Can they now impersonate everyone on the server?

yes. that is how IDs work. This is explicitly laid out in the spec:

Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server

[nightpool]

I mean, this is really at it's root, a consequence of trusting the DNS system, right? And I mean, i'm all for DIDs but I don't think they're really feasible in the short run—frankly, until browsers support them I don't see much progress in making them user-transparent enough to use everywhere.

So unless we decouple ourselves from web technologies entirely, we're stuck with the current domain name system.

[jaywink]

How do you trust that a key is associated with an actor? Well, you probably looked up the actor's id and found a key and said "okay, that's their key now". Fine.

Of course this depends totally on the implementation, but unless the protocol has some mechanism for this, a key shouldn't change. If the key is suddenly different, the remote server should assume the identity is not the same. They shouldn't just "update the key".

In a world where all messages are signed, losing your key is pretty much losing your identity. It's as simple as that. Maybe you are right about the upgrading keys necessity for generations to come. But one could argue putting this extra complexity is just leading to all developers having a harder time, which makes the whole system less reliable. KISS.

[nightpool]

@jaywink what you're proposing is one way of addressing the situation, but it's not a way that ActivityPub supports or recommends. Identity is tied to the actor ID.

[cwebber]

Right... Zooko's triangle means any naming system can choose two out of three: human readable, decentralized, unique. DNS chooses human readable and unique, at the expense of decentralized... but the uniqueness only applies to the slice of time you're currently reading DNS from.

DIDs have a tradeoff: they don't have a human readable component, but they are decentralized and unique. This means that if you want to square the triangle and add a human-readable component you're going to need something like petnames.

While I think DIDs are the right approach, I agree that it's "frontier territory" at the moment. I think this will change in the next couple of years (if you listen to recent conversations with Tim Berners-Lee it's clear he agrees that DNS is the weak link of the web, but of course that doesn't mean that browsers will likewise adopt).

If they key suddenly is different, the remote server should assume the identity is not the same. They shouldn't just "update the key".

In a world where all messages are signed, losing your key is pretty much losing your identity.

My first 1024 bit PGP key is from 2006; that's close in age to some of our earliest federated social web systems; OpenMicroBlogging (predecessor to OStatus) came out in 2009 iirc. I've had the same email address since around 2002 or so... I'd like my social identifier to last at least that long. Ideally a lifetime.

If you're suggesting that our identities on which we build our systems have an expiration time of about a decade, that's an admission up front that we aren't planning for the long term.

Edit: @jaywink thinks I'm taking their comment too seriously and I agree. Nonetheless, this is serious business! :)

[jaywink]

@nightpool, I wasn't proposing anything. Also, this isn't the ActivityPub issue tracker.

[WisTex]

I know I am extremely late to the game, but what if there were two keys, instead of one?

One key for the user/channel. One for the fediverse server.

If someone takes over a domain and reinstalls the same fediverse server, they are unlikely to know the previous server key and previous user keys. You can then decide how you want to handle it if one or both changes.

• Server key changes; User key stays the same
  • Treat as the same user, since the user's key did not change and that key belongs to the user.
• User key changes; Server key stays the same
  • Default mode: Treat as the same user.
  • Strict mode: Treat as a different user, unless and until they use an account recovery method.
• Server key changes and User key changes
  • Always treat as a different user, unless and until they use an account recovery method.

The server where you authenticate the identity can pass a parameter defining default or strict mode. If the fediverse server allows IDs to be reused, it should pass "strict" mode. If the fediverse server does not allow IDs to be reused, or that particular user ID has only had one owner, then pass "default" mode.

Since we can't trust that "default" mode was not set by a malicious admin who took over the domain, the website attempting to authenticate the user can decide whether to ignore this variable. But it is unlikely that the new owner of the domain would have both the original server key and the original user key.

• If the user is only able to post comments or otherwise has limited access, then default mode should be fine.

• But if the remotely authenticated user is able to perform more sensitive tasks, then perhaps strict should be employed instead.

• And, as mentioned above, if both the server key and user key change, assume it is a new user.

To allow recovery of remotely authenticated accounts, you could give remotely authenticated users an option to set a recovery email and/or recovery phone number. This is only necessary if you allow remotely authenticated users to perform tasks that save non-federated data on your server. (Use case: allow remote authentication for a non-social website or non-social plugin to a social website.)

It's not perfect, but this would allow both the server and the user to change keys without losing their identity.