SKS Keyserver Network Under Attack

[Leo Gaspard]

> 1. We would have to ensure that all keyservers block the same
> uploads. One permissive keyserver is a backdoor into the entire
> system. We can’t block bad keys at reconciliation time for the same
> reasons that have been hashed to death already.

One way to do that, though it would mean officially sunsetting SKS,
might be to:

1. Publish an update to SKS that:
   - Blocks all uploads of any packet that is not a revocation signature
     packet (maybe also having to check the revocation is actually
     correctly signed, to avoid flooding of revocation packets to become
     the new flaw)
   - Embeds a hardcoded list of already-disrupted keys for which packets
     should be filtered-out when serving them

2. Pressure keyserver operators into updating

3. Kick all not-up-to-date keyservers from the pool after some delay
   deemed acceptable (shorter means less broken GnuPG, longer means less
   keyservers kicked out)
   Note: I do not know how the pool is handled. Maybe this would mean
   that the new update to SKS would need to stop synchronizing with
   earlier versions, and that the hkps pool should be turned off until
   enough keyservers are updated to handle the load?

Do you think such a plan might be reasonably done, to at least keep the
most basic functionality of not breaking existing installations and
allow them to keep revocations flowing? The biggest issue I can see is
it requires a quite big amount of development work.

Hope that helps,
  Leo