Re: [Sks-devel] About deleting keys

[Arnold]

On 10/29/2013 03:51 PM, Kristian Fiskerstrand wrote:
> 
> 
> On 10/29/2013 03:47 PM, Arnold wrote:
>> On 10/29/2013 02:30 PM, Kristian Fiskerstrand wrote:
>>> The discussion gets even more interesting when dealing with
>>> revoked keys. If an attacker (with compromised secret key
>>> material) is given the ability to deleting such a key from the
>>> server network and re-uploading a non-revoked version; The
>>> effective security of the whole system is compromised (or for
>>> that matter mallicious key server operators doing the same).
>>>
>>> There are good reasons for the servers being add-only by
>>> design... and you'll find several discussions on this in the
>>> past.
> 
>> True, the SKS *network* should be add-only by design. However, this
>> does not imply that each key server is required to _provide_ each
>> and every key in its database or in the SKS network by means of a
>> search.
> 
>> If the SKS network (currently) can operate based on search by hash
>> only (which I assume) and if no current practical use (other than
>> test or debug) is hindered by hiding the hash from search results
>> (disabling the option "hash=on"), then filtering search results by
>> means of a list of key fingerprints seems feasible to me.
> 
> 
> I don't understand your point here, can you please elaborate?
> For clients accessing the pool the results are simply a DNS round robin
> and the client connects to a given SKS server.

Good you mention the pool. From my point of view "the" or "a" SKS network is 
just a
number of individual key servers running on individual hosts, operated by
individual operators/administrators. The operators have little agreements with a
few other operators to peer with each other and thus form a network. From this
point of view our pool is just one SKS network. Multiple may exist in the world.

Our network provides additional services besides offering keys and synchronising
among many servers. We provide a single 'server host name' (DNS) that resolves 
to
multiple key servers with some kind of quality in terms of availability and
completeness of the database.

I deliberately separate the two. First thing is the possibility to hide / 
remove /
whatever a key from a network of individual and independent key servers 
(operating
under different local laws). If that is sorted out, we can discuss how to 
continue
to provide the additional services like the single DNS for the whole network and
maintain our own lever of (internal) quality.

Hope this explains my point.

> If there is fragmentation in the network we'd have to split the servers
> (probably exclude servers

Excluding servers might not be scalable well as more countries implement some 
kind
of privacy law.

Just a thought, but this should really be step two. The DNS servers of the 
NTP-pool
(http://www.pool.ntp.org) dynamically provide 'nearby' pool servers. We might do
the opposite and provide 'far away' servers as it is unlikely those servers are
forced to remove 'nearby' keys.



> with deleted keys).

My suggestion was not to delete a key, but merely to hide it in search results 
(to
the highest degree possible). That highest degree possible is IMO a must to 
prevent
lawyers actually demanding (and legally enforcing) deletion of the database.

Arnold