NIP-41: simple account migration

[pablof7z]

This NIP introduces a simple way in which a pubkey can migrate to by whitelisting a new pubkey ahead of time.

TL;DR:

• Pubkey A whitelists Pubkey B as its next key ahead of time (e.g. by a social client). Whitelisting event is NIP-03-opentimestamped.
• Pubkey B publishes "migration" event. Also NIP-03-opentimestamped. After 30 days, compliant clients replace old pubkey with new one.

Viewable here

[pablof7z]

Important note

I still think we should have social recovery, pubkey nuking and other stuff that was discussed in other PRs but I want to get a first building block merged before we open other cans of worms.

[arthurfranca]

Is relying on bitcoin existence good for such important protocol feature? I mean, who knows what will happen to bitcoin after CBDCs or after some new fancy future crypto coin launch? Related draft PR using relay clocks instead of OTS: #782

But if people think OTS is the way to go, consider using "z" (#539 authorized deletion pubkey tag) set to the backup pubkey to prevent hacker from deleting previous kind:1776 event.

[nvk]

Is relying on bitcoin existence good for such important protocol feature? I mean, who knows what will happen to bitcoin after CBDCs or after some new fancy future crypto coin launch? Related draft PR using relay clocks instead of OTS: #782

But if people think OTS is the way to go, consider using "z" (#539 authorized deletion pubkey tag) set to the backup pubkey to prevent hacker from deleting previous kind:1776 event.

Yes, trying to avoid depending on bitcoin is important. But let's not make that be the line in the sand. We depend on the internet. We depend on electricity. We don't exist in a technology vacuum.

Out of all the proposals thus far this is by far the simplest and most straightforward.

[staab]

So does this mean events published with the new key aren't considered valid for 30 days? It seems like clients could eagerly respect the migration event and switch immediately to the new key, revoking that trust if a competing migration event gets published.

[pablof7z]

Perhaps 30-days is too long a time-window, but I think some delay is needed, otherwise an attacker publishing a revoking event would get exclusive control of the user's key and make things really difficult.

Adding the ability to have to rollback a migration opens a lot more complexity in my opinion, I think once a migration event is effective it should not be possible to roll it back.

But maybe 30-days is too long and this should be more like 2 weeks. Users can also use watchtowers to timestamp+publish kind:1777.

[fiatjaf]

30 days is not a long time window, in fact it is a short time window.

Clients that want to get fancy about it can follow both keys during that timeframe and add warnings to the users or something like that, as long as the result after 30 days is the same -- but these tricks don't have to be specified in the NIP.

[jb55]

On Wed, Oct 18, 2023 at 11:29:49AM -0700, nvk wrote: > Is relying on bitcoin existence good for such important protocol feature? I mean, who knows what will happen to bitcoin after CBDCs or after some new fancy future crypto coin launch? Related draft PR using relay clocks instead of OTS: #782 > > But if people think OTS is the way to go, consider using "z" (#539 authorized deletion pubkey tag) set to the backup pubkey to prevent hacker from deleting previous `kind:1776` event. Yes, trying to avoid depending on bitcoin is important. But let's not make that be the line in the sand. We depend on the internet. We depend on electricity. We don't exist in a technology vacuum. Out of all the proposals thus far this is by far the simplest and most straightforward.

As much as I like OTS & bitcoin, I think tying a core protocol feature to it would be a mistake. Especially if we want mass adoption of this NIP for future keys.

[jb55]

Although reading through this I don't see a better way than OTS... 🤷‍♂️

[pablof7z]

Although reading through this I don't see a better way than OTS... 🤷‍♂️

Yeah, me too; we need to anchor to something that we can trust keeps order of events.

The important thing is that I think we should have multiple mechanisms to do this (e.g. social recovery), and I think this is a simple one that would work. Every time we've discussed this topic we've let perfect+complete be the enemy of having a working building block.

How about we merge this and we add other mechanisms to it later?

[erskingardner]

I like this – it's simple and a great start. Obviously, it would be better to not anchor to specific external services, like Bitcoin, but I think we're all aware that this is just a first step and we'll continue working on more complete solutions in the future.

[fiatjaf]

I don't think this should be seem as a "core protocol" thing or a mandatory change. This is just one method, very fallible, to try to rescue people who have lost their keys. I think the NIP should be phrased as such and the expression "key rotation" should be removed and replaced with "identity recovery" or something like that.

Given that, I don't understand the pushback against Bitcoin here while NIP-57 depends much more deeply on Bitcoin and it's a much more widespread feature and entangled with the idea of Nostr.

Also, the Bitcoin dependency here can be completely hidden from end-users very easily, it's not as if clients will stop working if you don't have a full node running on your phone because of this.

[vitorpamplona]

So, If I am an attacker and my target doesn't have a white-listed key to migrate to, I can get my target's nsec, migrate my target's posts to a new key that only I control, and shut my target away from his/her own posts?

If this is true, then we better force all keys to white-list their next one asap.

[fiatjaf]

We need a "nuke account" option for when someone is doing that and you don't have a whitelisted account prepared.

"someone is trying to steal your account, nuke it?"

The nuke only works after 30 days too, to prevent people from stealing others' accounts and nuking them.

I also think we should increase this interval. 30 days is not enough.

[pablof7z]

So, If I am an attacker and my target doesn't have a white-listed key to migrate to, I can get my target's nsec, migrate my target's posts to a new key that only I control, and shut my target away from his/her own posts?

If this is true, then we better force all keys to white-list their next one asap.

Yes. Agreed.

I think the onboarding process of new users should have some kind of disaster preparation (which is standard in other systems where information has some kind of value ("e.g. store this 2fa backup codes"). Probably not at first but after a user has used a new account "enough".

[arthurfranca]

Please consider the z tag (#539) to prevent deletion of an old 1776 event . Just privkey-B would be able to delete it on supporting relays. Like this:

{
    "pubkey": "pubkey-A",
    "kind": 1776,
    "content": "",
    "tags": [
        [ "p", "pubkey-B" ],
        [ "z", "pubkey-B" ]
    ]
}

With that, there is no need for the 30-days delay. Client just picks the oldest one, which the attacker won't be able to delete.

Edit: also add [ "z", "pubkey-B" ] to kind 1777 so that attacker can't delete it too before clients notice it.

[pablof7z]

Please consider the z tag (#539) to prevent deletion of an old 1776 event . Just privkey-B would be able to delete it on supporting relays. Like this:

{
    "pubkey": "pubkey-A",
    "kind": 1776,
    "content": "",
    "tags": [
        [ "p", "pubkey-B" ],
        [ "z", "pubkey-B" ]
    ]
}

With that, there is no need for the 30-days delay. Client just picks the oldest one, which the attacker won't be able to delete.

The 30-day window is needed regardless of the 1776 deletion; you need a time window because the attacker can publish a migration event before you do (they would publish a delete before you do and you need multiple kind:1776s in case you lose the key of the first kind:1776 you published.

kind:1776 are not deletable already per this NIP, the z tag is more complex, we can just ban deletion of a specific kind.

[arthurfranca]

kind:1776 are not deletable already per this NIP

@staab posted here some use cases for delegating deletion. With the "z" tag we don't need to update relay code every time a new use case comes up.

you need a time window because the attacker can publish a migration event before you do

Hmm got it. This is because of the [ "relays", "relay1", "relay2" ] tag on kind:1777 so you can't previously publish a kind:1776 event cause the attacker may use other relays.

[fiatjaf]

do we need this? I feel like this should be a client preference. or clients prompting the user when performing the migration: "also mute the old key?"

it doesn't hurt to have this here, of course, I'm just thinking that every line we can eliminate from the NIP makes is more likely to be read.

[pablof7z]

hahhaa, yeah, I debated whether to add it or not.

I'll take it out.

[fiatjaf]

@jb55 @arthurfranca #158 is a way to do this without relying on Bitcoin or OpenTimestamps. As the PR says this just one option, we can have many, and this can be one of them we can investigate in the future.

[pablof7z]

Let's remember the goal:

We want to have one building block to start working on account recovery/key rotation/identity management/whatever you want to call it.

This NIP won't be the last that's said on this subject, but we need to take a first step that moves us closer to the goal of allowing people to take action to preserve their identity in nostr.

[fiatjaf]

Are we ok to merge this?

[vitorpamplona]

Are we ok to merge this?

Do we have a couple implementers to make sure things are good?

[fiatjaf]

Good point, I had forgotten about that. Let's wait for the implementations.

[pablof7z]

I'll write a micro-app for it 👍

[shocknet-justin]

This is really just another delegation spec and the knocks on NIP-26 apply, so it would make more sense to improve delegation overall than contrive a new pre-delegation spec.

[pablof7z]

This is really just another delegation spec and the knocks on NIP-26 apply, so it would make more sense to improve delegation overall than contrive a new pre-delegation spec.

there is no delegation token, no relay tracking of pubkeys, there is no execution of conditionals nor make-believe scenario where executing this is a happy-path. Getting your key compromised is still a very bad thing and not part of a regular user's flow.

NIP-26 and this are absolutely different in implementation and goal

[staab]

I can't think of a better way to do this, but I really don't like the waiting period. If the new key is not yet considered valid and may be an attack, but the old key is lost or compromised, that means the user is effectively temporarily banned from nostr, doesn't it? If so, I don't think this is an MVP, it would be an awful UX (not as bad as losing your key permanently, but still).

I still think social recovery of some kind, or a name registry could improve this, but I'm not sure how.

[shocknet-justin]

there is no delegation token, no relay tracking of pubkeys, there is no execution of conditionals nor make-believe scenario where executing this is a happy-path. Getting your key compromised is still a very bad thing and not part of a regular user's flow.

NIP-26 and this are absolutely different in implementation and goal

I don't see how whitelisting a key is any different than signing a delegation event. I would argue too that 26 should be done in middleware or client side as well.

Provisioning a user with forward compromise in mind is good conceptually, but that could also be a nip26 a cold key similarly...

Timestamping is a nice add and it's a good usecase, but it's unconvincing that this isn't part of a larger delegation discussion.

[pablof7z]

I don't see how whitelisting a key is any different than signing a delegation event. I would argue too that 26 should be done in middleware or client side as well.

The main difference is that, until a migration even is signed, the new key has no special attributes or significance, in fact, the new key does never really have any special significance, the migration event is just a hint to clients that they should follow a different pubkey, whereas in NIP-26, relays and clients must to a lot of heavy lifting to validate the conditionals of the token (and, more importantly, an increasing amount of heavy lifting). NIP-26 imposes a burden on relays to track these different delegation tokens, which, if it would have been widely adopted, it could have crippled relays significantly.

Keep in mind that NIP-26 is meant to be used as a way to use multiple keys to signify the same identity concurrently

[shocknet-justin]

I don't see how whitelisting a key is any different than signing a delegation event. I would argue too that 26 should be done in middleware or client side as well.

The main difference is that, until a migration even is signed, the new key has no special attributes or significance, in fact, the new key does never really have any special significance, the migration event is just a hint to clients that they should follow a different pubkey, whereas in NIP-26, relays and clients must to a lot of heavy lifting to validate the conditionals of the token (and, more importantly, an increasing amount of heavy lifting). NIP-26 imposes a burden on relays to track these different delegation tokens, which, if it would have been widely adopted, it could have crippled relays significantly.

Keep in mind that NIP-26 is meant to be used as a way to use multiple keys to signify the same identity concurrently

I concede that this proposal is better for the stated usecase, and others. That being the case, I think it should be generalized for usecases that include following multiple keys, not just replacing a revoked one.

[pablof7z]

I can't think of a better way to do this, but I really don't like the waiting period. If the new key is not yet considered valid and may be an attack, but the old key is lost or compromised, that means the user is effectively temporarily banned from nostr, doesn't it? If so, I don't think this is an MVP, it would be an awful UX (not as bad as losing your key permanently, but still).

I still think social recovery of some kind, or a name registry could improve this, but I'm not sure how.

Keep in mind that the waiting period is an absolute last resort; I don't want to muddy the waters further in this simple PR, but in the flow I have in mind I imagine clients allowing users to verify out of band that the migration event is not an attack, the verifying user could sign a kind:1 where the migration event is referenced and leverage a WoT in this way. The social migration in this sense leaks into this scheme organically.

[gregorygmwhite]

Definitely not blocking, but would it help to allow folks to set a waiting period before a kind 1776 "goes into effect" and a kind 1777 would be respected?
That way an attacker can't just publish a new 1776 and then a 1777 immediately after compromising an account. The only recourse right now is a contested migration which reduces the automatic update to the follower graph.

Just to clarify here; there is no "contested migration", there's always a very clear kind:1777 that takes precedence: whichever valid kind:1777 points to the oldest valid kind:1776 is the winner; there can't be any nuance to this so I wanted to make this point very explicit 😀

Which takes me to my main response to this comment 👇

Maybe this NIP could introduce an optional field when someone creates their 1776 that they set an optional time period (X days) they want clients/relays to wait before respecting the new 1776?

This introduces additional complexity and ambiguity that, I don't think, warrants it. What if you publish a kind:1776 with a "go into effect after 1 day" but then your life conditions change when you need to publish your kind:1777 and 1 day is nowhere near enough? It introduces implementation ambiguity and increases the complexity in which a client might do it wrong.

The 60-day time window is a line of defense; like @fiatjaf mentioned a few times, this is not something people should be doing on a regular basis.

You're right I just didn't understand it like I thought I did!

[vitorpamplona]

I am reading this again with a different perspective: Do we really need all these steps to simply notify followers that the author (or an attacker) of the key is migrating to a new key? This NIP is clear: Clients should present a message to the user and it's the user's responsibility, after evaluating the veracity of it, to decide to migrate or not. How would a user decide? I am assuming the person will look at other people's follows that might be closer to the person to see if they migrated first. It's a pure social trust decision tree. The rest of the NIP is not adding that much.

Maybe that is what we must codify. A person publishes a key migration at any time, no need to sign/verify with OTS. Then the person reaches out to close friends he/she is following to update their follow list to the new key. When showing the key migration popup to non-so-close users, the popup should also bring folks who already shifted over to the new key that are close to the user. The bigger the movement, the more accurate it gets.

There is no need to publish keys beforehand and there is no automatic migration. There is only a popup.

If an attacker is successful in sending a key migration, neither the original key, nor the new key are safe. The user will have to create a third key and convince his friends to migrate to the third one. There is not much a cryptographic scheme can do in this case.

Again, the secret for a successful migration is on the social graph, not on the cryptographic layers of a migration scheme.

[erskingardner]

@vitorpamplona I agree with you that the client-side flow should leverage WoT and show users some evidence that the move is legit.

That said, I still think it's important to have the OTS and pre-defined keys to help mitigate social engineering attacks. Otherwise, it's far too easy to trick a few of the person's followers into migrating over and then the weight of those few would likely cause everyone to migrate to the new key without doing much out of band verification.

At least with OTS and pre-defined keys you're adding an extra line of defense for the owner of the key that an attacker would have to get through.

[pablof7z]

I am reading this again with a different perspective: Do we really need all these steps to simply notify followers that the author (or an attacker) of the key is migrating to a new key? This NIP is clear: Clients should present a message to the user and it's the user's responsibility, after evaluating the veracity of it, to decide to migrate or not. How would a user decide? I am assuming the person will look at other people's follows that might be closer to the person to see if they migrated first. It's a pure social trust decision tree. The rest of the NIP is not adding that much.

The point of the NIP is not that message, that is to appease the "X days is too long of a time-window" argument (which I understand) -- the point of the NIP is the automatic migration when the migration event is not disputed.

A lot of people who have leaked their keys already have an "OLD ACCOUNT, MIGRATED TO XXXX" on their kind:0, and yet they still have people following it. This manual action is not enough, particularly if the person stops writing from their old account, which they should if they key has been compromised and they want their followers to not be exposed to scams.

There is no need to publish keys beforehand and there is no automatic migration. There is only a popup.

If an attacker is successful in sending a key migration, neither the original key, nor the new key are safe. The user will have to create a third key and convince his friends to migrate to the third one. There is not much a cryptographic scheme can do in this case.

Again, the secret for a successful migration is on the social graph, not on the cryptographic layers of a migration scheme.

From an UX point-of-view, the key to a successful migration is that there is a migration; requesting a manual action from each individual user to update their follow lists is not enough imo, and this is a very simple, no-crazy cryptography involved way of having a fallback system to accomplish such thing.

Like I said before, we'll probably end up with a few different approaches to accomplish this way of protecting your account and there is a place for social recovery, this scheme doesn't depend on that, it just mentions the feasibility of reducing the X-day time window.

[vitorpamplona]

the point of the NIP is the automatic migration when the migration event is not disputed.

I am not sure if we should ever do automatic migration of a person's contact list. Especially when so many things can go wrong: like if the user doesn't have a previous key migration event, or if he/she doesn't act quickly enough, or if the user doesn't even notice somebody else is taking over their account because their client doesn't implement this NIP.

A lot of people who have leaked their keys already have an "OLD ACCOUNT, MIGRATED TO XXXX"

Yep, but only because we have not had a structured way to describe that in Nostr Events that can be parsed and displayed to the user. If that is all we want, we don't need the extra stuff.

At least with OTS and pre-defined keys you're adding an extra line of defense for the owner of the key that an attacker would have to get through.

Only for users that have a client that instructs them to create the kind:1776 as early as possible. For everyone else, this PR adds a new line of attack.

I am specifically concerned about users who just leave Nostr and come back 6mo to a year later. They won't be using any client to watch out and react in the 30-day period.

[pablof7z]

the point of the NIP is the automatic migration when the migration event is not disputed.

I am not sure if we should ever do automatic migration of a person's contact list. Especially when so many things can go wrong: like if the user doesn't have a previous key migration event, or if he/she doesn't act quickly enough, or if the user doesn't even notice somebody else is taking over their account because their client doesn't implement this NIP.

I think this is the crux of where we don't agree, I don't think that's a sensible tradeoff.

At least with OTS and pre-defined keys you're adding an extra line of defense for the owner of the key that an attacker would have to get through.

Only for users that have a client that instructs them to create the kind:1776 as early as possible. For everyone else, this PR adds a new line of attack.

I asked around on nostr and pretty much everybody that responded said they would publish such a whitelisting event.

I am specifically concerned about users who just leave Nostr and come back 6mo to a year later. They won't be using any client to watch out and react in the 30-day period.

If they don't come to nostr for such a long time and their key is compromised and they didn't even find out about it then that key was probably worthless and they should start fresh 🤷‍♂️

[erskingardner]

Only for users that have a client that instructs them to create the kind:1776 as early as possible. For everyone else, this PR adds a new line of attack.

What's the new line of attack? If you don't have control of the private key you can't publish any valid events, including 1776. If you do have control, then why bother?

[vitorpamplona]

I asked around on nostr and pretty much everybody that responded said they would publish such a whitelisting event.

I saw it. My point is that people who didn't see your message wouldn't have created such a whitelisting event which would open them up for a separate attack that didn't exist until this PR arrived. If this was part of the Nostr protocol and EVERY client had to whitelist as soon as the user creates an account, that would be better. But that's not how Nostr works.

I think this is the crux of where we don't agree, I don't think that's a sensible tradeoff.

I would probably code this only until line 65. White-list and migration events are fine. The automated migration seems to create more problems the solutions right now. I would just ask the user if they want to migrate or not and just provide trust via social graph and the OTS verifications. But it would be the user's decision. Nothing changes without it.

[pablof7z]

I asked around on nostr and pretty much everybody that responded said they would publish such a whitelisting event.

I saw it. My point is that people who didn't see your message wouldn't have created such a whitelisting event which would open them up for a separate attack that didn't exist until this PR arrived.

This would assume that their nsec is currently compromised, in which case they are already rekt. Say a user who hasn't used nostr in the past year but doesn't have their key compromised, they open a nostr app in one year and the app asks them if they want to setup a recovery key. In a way, is slightly similar to those "download backup 2fa codes" flows people are used to.

If this was part of the Nostr protocol and EVERY client had to whitelist as soon as the user creates an account, that would be better. But that's not how Nostr works.

Not really, I think until there is something to protect, this backup key shouldn't be part of the onboard, but of course, that's up to apps to choose how they design this. I'm mainly thinking about how apps like Duolingo do it where they don't ask you to do any "progress saving flow" (like creating an account) until there is enough investment for the user to warrant jumping through any hoop. Again, this will probably be different on a per application basis.

I think this is the crux of where we don't agree, I don't think that's a sensible tradeoff.

I would probably code this only until line 65. White-list and migration events are fine. The automated migration seems to create more problems the solutions right now. I would just ask the user if they want to migrate or not and just provide trust via social graph and the OTS verifications. But it would be the user's decision. Nothing changes without it.

At the end of the day, that's up to the user since it's their signature going on the kind:3 or 30000 and up to the application they're using to choose how to handle this.

[vitorpamplona]

This would assume that their nsec is currently compromised

Correct. But one thing is to just be compromised. A very different thing is the attacker pretending to be the user, migrating all followers to a new profile, and shutting off the user from the new account. The first is bad ("just" impersonation), but the second is worse (stealing the account w/ followers). And users that didn't know this COULD happen will be really mad when it does happen.

At the end of the day, that's up to the user since it's their signature going on the kind:3 or 30000 and up to the application they're using to choose how to handle this.

But that's not what this PR is saying. The PR advocates automatically migrating after 60 days, with or without the knowledge of the user.

[fiatjaf]

We can change the PR to say the behavior is implementation-specific.

A natural flow to me would be for clients to display a warning every now and then, or a fixed label somewhere on the screen, for the entire duration of the 60-day period.

Having such a thing would force users to look before they are automatically migrated -- or force them to decide to migrate or not to the new key.

This UX wouldn't be very different from the one we have today, in which an attacker can steal someone's key and start publishing notes every day saying: "this key is compromised, switch to my new account npub1..." -- pointing to an account controlled by the attacker.

[ursuscamp]

If there even is a solution to this problem, I don't know if this is the one. I see two potential issues here, both based around the idea of someone stealing a recovery kit:

Complexity

The first, and least, problem is unnecessary complexity. If a "recovery kit" includes the original timestamped 1776 event and the backup key, I don't think there is really any point in having a second 1777 event. If they steal the kit, the attacker could just publish the 1777 event themselves. Especially since created_at doesn't matter, only when a client first sees an event, you may as well just use one event, 1776. Once it gets published, that starts the 60-day clock on recovery.

I don't really know what value the 1777 event really adds to this scenario.

Griefing

The second and more serious concern is that of griefing.

If your recovery kit escapes containment, they can grief your entire set of followers and future followers forever by publishing 1777 events. Even if they don't get your followers to move, your existing followers will always be hounded by for all time with "Check if this key migration is valid". I don't see a good way around this.

If relays decide to expire individual 1777 events, the griefer can republish a new kind 1777 event. If relays automatically blacklist future 1777 events associated with this migration, there will always be new relays that don't know about it. If we expect clients to remember the setting, there will always be data resets, and there will always be new clients and new users.

Losing your recovery kit means you (and all of your followers) will always potentially be hounded by this for all time. New follower will get hassled, and you will always worry whether you're losing your social graph to scammers. This means if you lose your recovery kit to a scammer or griefer, you will eventually still have to move to a new key the old fashioned way.

Now you have to keep two keys safe, not just one: You're main key and recovery kit.

So you think, okay, I'll have a second, even more cold-stored recovery kit which is timestamped even earlier. Now you have three keys you have to keep secret and safe: P for Prime, B1 for Backup-1 (oldest timestamped) and B2 for Backup-2.

• If P is compromised, you can move to B1 or B2 and throw the other away.
• If B2 is compromised, P is now subject to eternal griefing, but at least you can move to B1 because it's stamped earlier.
• If B1 is compromised, P is now subject to eternal griefing, and B2 is useless because it's stamped later.

After all of this trouble and complexity and extra care, what you get is a system that still relies on social recovery: Someone messaging you to ask if a recovery is actually real.

[wanchaidreaming]

Couple of ideas.

Recovery key recovery
NewAccount Privatekey signed by NewAccount Recoveryprivatekey with recovery bit set
Only Recoveryprivatekey can set NewPub bit
If NewPub bit set then unfollow NewAccount and follow NewPub

Social recovery
NewAccount Privatekey nominates X other PubKeys via mechanism that requires acceptance with valid sig of request and recovery bit is set, migration bit false
If recovery bit is set, X other PrivKeys (or threshold per for e.g. FROST) required to set NewPub bit and add valid (signed) NewPub
If NewPub bit set then followers notice and unfollow NewAccount and follow NewPub

[erskingardner]

What's the status of this one @pablof7z? Feel like we should merge some version of this to have it out there....