Why are Fireproof messages irrevocable?

[vecna13]

It's not immediately obvious to me why Fireproof messages can't be reversed. I can imagine a user saying at one time that they want to be fireproof, then later deciding they don't want that much responsibility, and they want the BurnDown recovery option to be re-enabled.

I'm guessing the attack in mind is compromising one of the Actor's private keys, using it to un-fireproof the Actor, and then issuing a BurnDown for them. Is that right?

I think other readers might also be confused about this. It might be helpful to add more detail about this to the spec.

[soatok]

There's no strong argument either way. I may add an un-fireproof message type later.

[IreneKnapp]

As somebody who is likely to use Fireproof, I do think it is a good idea to also offer DouseInOil or whatever you want to call it. I remember how browser vendors had to remove support for HPKP because corporations had a habit of using it to irrevocably lock themselves out of their own domains. In general, for any security precaution anyone provides, there will be some people or organizations who turn it on for bad reasons and without fully understanding its implications. We should let those people fix their own problem so it doesn't become everyone else's problem also.

[soatok]

Excellent point.

[cultpony]

It might be valuable to allow FireProof messages to include an expiration; HSTS and HKPK both had that. The recommended default should be no expiration or like 1 year year or higher, but it'd allow admins to reclaim/recycle usernames eventually, even if they issued a FireProof message.

Other applications would be allowing the account of a deceased to be recovered as well as allowing a recovery option that does not involve having to immediately trust an admin.

Most people might quite happily be able to use a FireProof timeout of 1 month, as long as they log in once a month, a renewable can be published and the fireproof key remains safe.

---

And on a slightly different note, if keys become revocable, timeout or not, then there should be a rate limit on message publication per account. Mostly so the public key directory isn't bloated by high frequency messages.

[raphaelahrens]

I think in general a delay for BurnDown would reduce the harm which can be done, with an illegitimate BurnDown. The operator of the PKD should be able to set a minimum burn rate. Maybe the User could suggest a delay.

The advantage of a delay is that the actors would have more time to realize that a BurnDown has happened, while the attacker/operator is not able to issue a new AddKey into the PKD in the delay period.

I see one issue with delays, but I guess this is already the case, but would become more urgent to fix with delays. This does not have to be true since I still need to fully grasp the spec.

A BurnDown could be monitored by an attacker and then there is a race condition who will send their AddKey first. Provided the attacker is able to send AddKey to the PKD, so I guess an AP service operator could or an actor via a spoofable AP service Implementation. Since it is unclear who send a restarting AddKey this could even be repudiated later by an operator.

[soatok]

Proposed change in #27