SKS Keyserver Network Under Attack

[Leo Gaspard]

Mirimir via Gnupg-users <gnupg-users at gnupg.org> writes:
>>    - Embeds a hardcoded list of already-disrupted keys for which packets
>>      should be filtered-out when serving them
>
> That's what I meant. Plus some mechanism for testing keys, so poisoned
> ones are blocked, as soon as possible.
>
> It'd also be useful for SKS to report "this key has been poisoned", and
> suggest alternative sources, rather than just failing silently.

I think we can't rely on humans actually reading the output, even if
GnuPG was able to display the output on eg. `--refresh-keys` in a way
understandable by a human.

Also, the aim of my suggestion was to actually *not* block the
keys. This second point of part 1 is there to just filter some hardcoded
list of packets, thus making key updates still propagate.

The first point was there to prevent additional keys from being
poisoned, and the second to limit the damage caused by already-existing
keys -- the first one is unfortunately quite necessary, as
sks-keyservers can't reasonably be coordinating changes on the ~220
keyservers every time a new key gets poisoned (or even twice, for that
matter, one flag day is already bad enough)

>> 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.
>
> But less work than actually fixing SKS, right?

Well, nowadays “fixing SKS” means “making hagrid able to synchronize its
cryptographic-only content and propagate third-party signatures under
some circumstances”, as far as I understand.