I want to discuss how to proceed in case the node key gets compromised. We are taking a lot of effort to keep the key in cold storage, but what is really the implication when the key falls in the hands of an attacker.
Let us assume I still have a backup of the node key. Then I can immediately retire the stake pool and keep the damage limited.
If your node.skey is compromised, it is game over for the corresponding pool.
As you said, best is probably to retire the pool immediatly, but:
A point still is unclear to me (yet), can an attacker respawn a pool with the stolen secret keys after it has been retired and that way still benefit from the unsuspecting delegators ?
Anyway, gesticulations to make delegators join your new pool won’t look very good.
A point still is unclear to me (yet), can an attacker respawn a pool with the stolen secret keys after it has been retired and that way still benefit from the unsuspecting delegators ?
The pool retirement could be implemented as a kill switch. Then it would not be possible to respawn or otherwise manipulate the pool anymore.
You cannot retire a pool if the adversary got your key even if you have a backup. Cos, afaik the pool params update (rereg cert) ends (therefore overwrites) a retirement certificate. So it would became a mouse-cat catch game. I would let the owners know or if I would the owner then I would move the pledge out and would try rebuild the image for a new pool. And in every day for weeks or until the ol pool is deregd wouls send a pool (update sorry was typing on tablet} rereg certificate to the network. Anyway, you would be screwed up anyway.
But, I would apply different rule set i.e. retire cert overwrites the rereg cert but not vice versa.
I simple approach would be that the retirement certifiate always has priority over all other types of certificates for the pool. So pool retirement aways acts as kill switch.
You seem to be right, as confirmed by KH.
“You can register a pool with the same credentials having retired it. With a stolen key, it would be indistinguishable from the original I would think.”
So it is a proper disaster 
Kevin Hammond pointed out that there are resource constraints to implement a kill switch type of feature:
KH: You can register a pool with the same credentials having retired it. With a stolen key, it would be indistinguishable from the original I would think. Try it here
D: So it should not be allowed to reregister a retired pool for security reasons. IMO
KH: It would be possible to do that. You would need to scan the chain for all previously retired pools whenever a new one was registered though which has a resource implication (even if cached).
D: This could be solved by keeping all known pool keys in a cache and add a retirement flag. I guess when pool parameter updates are processed a similar cache is used to process the updates efficiently at the end of an epoch.
KH: The difference is that the number of pools doesn’t grow beyond some constant number, whereas the number of previously registered pools will grow over time. It might be an acceptable overhead.
D: Yes your right this is an issue. So now the challenge is to find a lightweight means to prevent the abuse of a stolen key.
It makes sense, And as AA would say
Your key, your pool, not your key not your pool.
but you can only register it if the rewards account wos cleared. so leaving 1 lovelace in the rewards account would not success in a pool re-registration?
If you’d lost the keys, then the thief could presumably withdraw that 1 lovelace, so you would need to keep the rewards keys separate from the other pool keys. It would also not be good from a network perspective (you would be reserving something that was no longer used, which we want to avoid).
Jared confirms: look after those cold keys, everyone, if you value your pool! He will be around during Alex Byaly’s webinar tomorrow evening.
Oh fun, I was on the testnet and accidentally wrote over my payment.skey. Now I cannot move those testfunds.
So there is no way to finagle this and move those funds now that the skey is compromised?
Glad I got to figure this out on the testnet before I start to play with my real ADA.