More robust handling of cases where username is reused or keys change

[trwnh]

Introduction

Possibly related to #4874

Currently, usernames are not changeable in Mastodon as a design decision. But other softwares do not necessarily want to make the same decision. This means that there are certain blockers that must be resolved, or else there will be breakage of profiles if/when usernames change. See #6837 for a notable prior incident of a manual username change, but also note cases that are more often wherein a profile may be suspended (causing deletion) but then restored (without the old data, but with the same username).

Authority

Firstly, it is important to consider the question of authority and authoritativeness when it comes to data (and especially linked data). The current prevailing model is to defer authority to the domain, since id is allocated as an HTTPS URI and is thus guaranteed to be globally unique by DNS. But the authority of DNS is not handled 100% correctly, primarily in two cases:

Webfinger acct takes precedence over ActivityPub id

By my understanding, there are several parts of the Mastodon codebase that use the acct for performing their logic, thus making Webfinger the most authoritative way to refer to accounts in Mastodon. For more detailed discussion of this, see #10745.

DNS can change

The other part of the issue is that a domain name will not always point to the same server. There needs to be a way to determine whether a given lookup is trustworthy.

Proposal 1: Establish root trust by signing profiles/keys with the instance actor

I'm not 100% familiar with how key management is done for actors currently, but I am vaguely aware that keys are used for HTTP Signatures, and that there exist some mechanisms for key rotation (but not blind key rotation, maybe? #9658)

Classical webs-of-trust use the concept of root trust to deal with the fact that you can never be 100% sure of any claim. If you first trust one key, then you should be able to assume some level of trust for anything signed by that key. You can have multiple roots, but you gain some flexibility by allowing for delegation of trust. And in the case of the ActivityPub network, you are effectively already delegating control of your profile to your domain/server/provider. Thus, it is not a radical extension to defer trust decisions to your instance. Your instance actor can handle the key management for you, so you don't have to do your own manual key management.

Proposal 2: Establish a web-of-trust for instance actors, using Trust On First Use (TOFU)

When an instance is first encountered in the wild, we already default to trusting everything we lookup from it. But if the instance changes and keeps the same domain, then it should no longer be treated as the same instance. Doing our own DNS resolution doesn't solve anything, because instances can change IPs if, for example, an admin migrates to a new machine. But with instance actors, we can assume that if the keys change (and the rotation was not valid), then we should no longer trust that instance (unless manually verified). This is known as Trust On First Use, and it is a strategy used by some XMPP clients when deciding which other clients are trusted or not (for encryption via OTR/OMEMO). TOFU has its limitations, namely in that there are some cases where frequent key changes occur (e.g. in XMPP, reinstalling your OS or getting a new computer/phone); however, we can assume that instance reinstallations are not a common or frequent event, so TOFU works fine for this. In the event that data loss occurs and an admin does reinstall the instance, it would fall on other instance admins to determine whether they trust this claim that the admin is still the same admin.

Actionable requests

• Give instance actors their own keys, if they do not have them already.
• Sign profile keys with the instance key.
  • In cases where actor keys change and the rotation was not signed by the old keys (e.g. in cases where the old actor keys were lost), defer to the instance actor for validation.
• Add UI in the admin panel to audit when instance keys change.
  • Add UI to mark the instance as "still the same instance" (accept key change) or "different instance" (reject key change).

[Neustradamus]

To follow this important ticket