sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] Potential problems running keyservers


From: Arnold
Subject: Re: [Sks-devel] Potential problems running keyservers
Date: Sun, 26 Oct 2014 17:09:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0

Hi,

On 26-10-14 10:17, Hanno Böck wrote:
> From my understanding the core principle of the pgp keyservers is that
> they have an "add only"-policy, meaning you can never remove something,
> just add further information to it (e.g. keys don't get removed, they
> expire or are revoked).

Correct.

> This opens up a couple of problems and I wonder if they have been
> discussed before and if there are any counterstrategies to them.
> 
> a) Someone could just flood the keyservers with random bogus keys. This
> would basically fill up the hard drives of the keyservers.
> b) Someone could grow a target's key by adding more and more
> signatures. This would quickly make downloading the key from the
> keyservers infeasible.
> c) Someone could use keys, keyids, signatures or whatever to store
> illegal data. (Basically this very same issue has already been
> discussed in the context of bitcoin [1])

These things have been identified in the past as 'possible issues'.

Some people on this list, like myself, would see measures implemented now to be
able to counter these issues at the moment they get real. Others argue nothing 
has
to be done at this moment. Currently, there are no developments or even 
strategies
to counter issues like these.

d) A fourth possible issue is the fact we store personal data. Many countries in
Europe have laws regarding the storage of personal data, including the right to 
get
removed. Up to now, we have had one server operator who had to close down due to
legal threats regarding this.

> I don't really see any feasible counterstrategies to these issues.

Situations c) and d) can be countered by making it impossible to retrieve the 
data
of keys that are listed in a local list that the server operator maintains. This
keys should not be listed in search results either. If getting keys by 
SKS-hashes
is excludeded from this mechanism, it would still allow SKS-sync as normal.

b) can be countered by setting a max. key-size servers accept. In this case a
server has to reject new material in case the resulting key is larger than a
certain size that has to be agreed among peering SKS-operators. To avoid loosing
revocation certificates, we could strip revoked keys from all unnecessary 
information.

a) is difficult... One could restrict the uploads from a certain IP, but a 
botnet
uploading to every known keyserver can still do a lot of damage.

> Given the speed one can generate and upload material to key servers
> (keys don't have to be valid to be accepted) I think all three scenarios
> could easily happen.

Yes, if someone wants to cripple relative easy key exchange, that is very well
possible. Without a public key infrastructure like our SKS-network, use of 
OpenPGP
for signing / encrypting e-mail, documents or server certificates
(http://web.monkeysphere.info/) will be much harder for the average user /
organisation.


> I'm curious what the thoughts of the people running keyservers are.

My € 0,02.

Arnold

> [1]
> https://www.reddit.com/r/Bitcoin/comments/1akyy4/what_happens_if_someone_inserts_illegal_content/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]