SKS Keyserver Network Under Attack

Mirimir mirimir at riseup.net
Mon Jul 1 04:26:06 CEST 2019


On 06/30/2019 08:55 AM, Andrew Gallagher wrote:
> 
>> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users <gnupg-users at gnupg.org> wrote:
>>
>> maybe I don't get the original idea - but I thought, it was to block *uploads/updates* which would poisson a certificate - not to blackhole them after they got poissoned?

No, I did mean blackholing poisoned certs.

> Hm, that’s not how I read it, although I could be wrong. It is possible to prevent submission of bad keys, but this just leads to new problems:
> 
> 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. 
> 
> 2. Although it may be possible to block an individual upload of tens of thousands of key packets, it will not in general be possible to prevent an attacker from incrementally increasing the number of packets attached to a key over time. If we impose a reasonable limit on the cumulative number of packets attached to a key, that key may never become undownloadable, but it will at some point become unmodifiable - so we have just transformed one DOS vector into a different one.
> 
> A 

It does seem that it's impossible to keep certs on the current SKS
network from being poisoned. I only see two alternatives: 1) fixing SKS,
and 2) replacing SKS. And meanwhile, preventing poisoned certs on SKS
from doing further damage.



More information about the Gnupg-users mailing list