API extension to prevent Certificate Flooding DoS

[ygrek]

Original report by Chris Laprise (Bitbucket: [Chris Laprise](https://bitbucket.org/Chris Laprise), ).

---

I don’t necessarily expect SKS to come out of maintenance mode to implement new features or do refactoring, but it would be good to at least see some discussion for resolving the current DoS crisis. With that in mind, I offer this proposal:

---

‌

The most straightforward way for SKS to resolve the DoS crisis from massive third-party key signing is to give certificate/key bearers control over the acceptance of third-party signatures.

When a signature is submitted for a key, hold it for a set amount of time in a “pending approval” state instead of directly linking it to the key. This would prevent the new signatures from being automatically downloaded when users request the key. The new signatures are linked (as usual) to the key only when the key holder downloads a new signature manifest and then posts back a signed manifest referencing the new signatures.

An additional fetching mode and also a posting/update mode must be added to the key server in order to accommodate the following process for accepting new signatures:

1. Key owner downloads a manifest of unapproved signatures.
2. Key owner locally views the manifest, and removes any undesired entries (ideally, one per line).
3. Key owner locally signs the manifest to approve.
4. Key owner posts the manifest and their signature to the key server.
5. Key server verifies the posted manifest and links the referenced signatures to the owner’s key, thus making the signatures available through the traditional key fetching process.

I think the above could be implemented without a great deal of effort and without any changes to OpenPGP itself. After all, OpenPGP is meant to give users the ability to protect & mediate their transactions with other entities. It only makes sense that the acceptance of third-party signatures into their key record be mediated with a signing process as well.

The key server could be configurable with the maximum number of new/unapproved signatures it will hold, and with the amount of time to hold them before they are automatically deleted.

Adding a ritual/process like the above also opens up an avenue for new tools that can examine & filter signatures for key holders similar to the way email SPAM filters operate. In such an environment, users can simply keep accepting new signatures ‘blindly’ as long as the volume remains low.

‌

---

Another type of mitigation, mentioned on the first Hagrid instance FAQ, would hinge on distribution of third-party signatures only via retrieval of the signer’s (not signee’s) record. But this requires a significant alteration to numerous tools that already implement WOT with OpenPGP, just to facilitate basic operation and checking of existing signatures.