Re: [Sks-devel] Oh, Jeeez...!

[Arnold]

On 24-05-16 18:17, Tobias Frei wrote:
> Adding proof of work can only prevent an attack that depends on a huge number 
> of
> useless keys.

Setting a maximum upload size can help and is easy to implement locally. 
Further,
it is possible to limit the rate at which a single IP (or IPv6/64) can upload 
new
or updated keys.

> Someone else once mentioned that a single key with an illegal image
> ID can already cause huge problems, and deleting such a key can become the 
> only way
> to be legally allowed to continue running a keyserver.

A possible solution I suggested a while ago is to have SKS synchronize only a
subset of the database. The Set Theory that SKS uses, can be applied to subsets 
all
the same. All we need is a good definition of the subset(s).

If we agree to synchronise only the keys modified in the last three months or 
so,
then everyone has the option to locally(!) delete keys that have not been 
modified
for some time. Right now we ask new operators to have a recent dump before we 
start
peering anyway. Yaron thought something like this is "totally doable" (see his
e-mail of  21 May 2015 21:16:36 +0000), but it needs work...


> About lacking keys, well, if the pool selection mechanism causes working 
> keyservers
> to be removed, that's a separate problem that needs to be solved after this 
> one, I
> think. It should not be an argument for or against this suggestion, but 
> instead
> needs to adapt to the current situation.

I guess the stats of SKS can be modified to show more stats, like the number of
keys in the subset that is being synchronised.

Arnold