change behaviour of zfs change-key (as by now - losing access to local and remote (backup) data is quite easily possible)

[mheubach]

This has already been discussed and having an attacker gaining root access to your system is already bad enough - but:
File by file encryption or even encryption of a whole block device takes time.
You don't want to present an already complete encryption of your data to an attacker by giving him such simple means like "zfs change-key" to render your data inaccessable.
He has to become root first - yes - but we all know how easy this sometimes is. The damage is immediate and no one can save you. Especially if your backup concept is replication of raw encrypted data (-w) as in that case the changed-key will also be replicated and thus you even loose access to your backup. This is Bingo! for any attacker.
So zfs change-key should not be possible without entering the old key.

[mheubach]

Just an idea:
How about making the master exportable, so it can be stored (offline) at a safe place. Of course this also needs some mechanism to restore the master key. But maybe this would be a very simple and safe solution for the problem.

[rincebrain]

I mean, the actual master is immutable, and ZFS architecturally isn't going to tolerate being able to actually change it, so the best you're going to do is be able to forcibly override unlocking with the key from backup without being able to unlock it already, but that also means that if you had an untrusted attacker who could export it, you get to rewrite your dataset entirely without zfs send -w to get a new key.

If your threat model is worried about the possibility of someone doing change-key on your host without you noticing before it backs up remotely, it might be worth exploring an option to make recv not propagate change-key requests...

[mheubach]

If your threat model is worried about the possibility of someone doing change-key on your host without you noticing before it backs up remotely, it might be worth exploring an option to make recv not propagate change-key requests...

This might be good and bad at the same time. Preventing propagation of the key change will for sure keep your backup copy accessible with the old key - but: If you change the key because it has been compromised, you have to make sure that in this case, the key change will be propagated.

I think the really best thing would be to make the master key exportable. Of course this master key has to be kept most secure - but it is your life insurance.