On 06/30/2019 08:55 AM, Andrew Gallagher wrote: > >> On 30 Jun 2019, at 15:07, Erich Eckner via Gnupg-users >> <gnupg-users@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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
