SKS Keyserver Network Under Attack

[Mirimir]

On 06/30/2019 10:37 AM, Leo Gaspard via Gnupg-users wrote:
>> 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)

I wasn't suggesting that. As long as only a few keys are being poisoned,
it's arguably not necessary, and too disruptive. But if this becomes a
game in the chans, that might become necessary.

>    - 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.

> 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?

Makes sense.

> 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?

> Hope that helps,
>   Leo
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>