HPKP-based persistent denial-of-service attack on web sites

Question

HTTP Public Key Pinning (HPKP) is a standard that allows a HTTPS website to specify which certificates it trusts, and instruct the browser not to allow any connection to that site that's secured by any other certificate.

Can this be used to facilitate a persistent denial-of-service attack on a website? Suppose an attacker compromises a website like cnn.com (say). It seems like the adversary could configure the webserver to enable HSTS and HPKP, with a pinning policy that specifies a certificate controlled by the attacker. The attack might be discovered and the legitimate administrators regain control, but everyone who visits cnn.com in the meantime will receive a HSTS and HPKP policy and their browser will cache it. As a result, their browser won't allow any HTTP connection to cnn.com (due to the HSTS policy) and will only allow HTTPS connections if the server uses the pinned certificate and public key. But since the attacker specified the pinned cert, it might be using a private key controlled by the attacker and not known to cnn.com. Consequently, after the attacker is kicked off, cnn.com has no way to terminate a SSL session using that attacker-chosen private key. So, all future connections from those browsers to cnn.com will fail.

The HPKP standard does suggest that browsers should set a maximum age for these policies, but it also suggests setting the maximum age to 60 days. So, if I'm understanding this correctly, it means that if an attacker temporarily compromises a website, then the attacker can ensure that the website will be absolutely unreachable for the next 60 days for all users who visit the website during the brief time when the website is compromised. Basically, any user who visits the website at a time when it is controlled by the attacker is "poisoned" for the next 60 days, and the website appears simply unreachable.

As website breaches are not unheard-of, this seems like it would be a rather severe outcome. This is a rather unusual sort of denial-of-service attack: it allows for irreversible vandalism of a site that there's nothing the website admins can do anything about, except to wait. the It also looks like this attack could be exploited against any website, even one that's not currently using HPKP, HSTS, or even HTTPS.

Have I understood this correctly? Are there any mitigations that a website can take to prevent itself from being DoS'ed in this way? Is there an argument that HPKP doesn't introduce any new DoS risk that's any more severe than what already existed before HPKP? Has this kind of persistent DoS attack ever been observed in the wild?

I've read RFC 7469, the standard that describes HPKP, and it doesn't seem to have any mitigation. It appears the attack I described would qualify as an instance of 'hostile pinning', but the standard doesn't seem to mention any useful mitigation for hostile pinning (apart from the max-age).

Answer 1

Reading through this memo, a link is given to the un-pin draft of Perrin here. I see two countermeasures against the scenario which you describe in this draft:

Let's start with the first one, which can be interpreted in different ways:

Whenever a client performing "pin activation" sees a hostname and TSK combination not represented in the "pin activation" pin store, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.

In my interpretation, the implementation of the above paragraph would mean that an attacker can only activate new pins for a very limited timespan. However, the attacker could still revoke older pins, it seems. Therefore, we move on to the second countermeasure described:

Nonrevokable tacks: A tack with generation 255 cannot be revoked. Such tacks MAY be used to minimize the risk that a compromised TSK private key could be used to affect site availability.

Thus, a server that has issued a non-revokable tack, could in fact keep using this tack forever. How I read that is that a server could create a key pair which is does NOT use, but for which it creates a non-revokable tack. (In Perrin's implementation, this would become one of the maximum of two PINs which cannot be deleted). In case the server is compromised, this key can be retrieved and used to undo the attacker's changes.

Whether or not this is implemented in current browsers, I don't know.

Edit: As @StackzOfZtuff pointed out in one of the comments, there is actually a transcript of an email conversation between IETF:WEBSEC and Perrin, pointing out to implement a TACK-like mechanism for HSTS.