|
From: | Olaf Gellert |
Subject: | Re: [Sks-devel] Blacklisting Keys |
Date: | Thu, 26 Feb 2004 10:54:34 +0100 |
Yaron M. Minsky wrote:
Blacklisting keys is a complicated topic, and it's something I've done some thinking and research about, but little implementation. here are a few of the issues that come up.* How to specify blocked keys? Do you use the whole-key-hash? That's problematic in that a single new packet resuccitates thekey. That's often not quite the behavior you want. You could specify the lead key packet, which is more robust, but has weirdnesses to it as well. For instance, let's say I drop a nasty packet into someone else's key. We'd like to be able to ban that packet without banning the whole key. * Should blocking be deep or surface? Surface blocking just prevents the key from being seen by clients, but the data is still stored in the database. This is reasonably good for blocking illegal content, but bad for dealing with denial of service attacks. * Deep blocking has its own problems, since it introduces persistent differences between different hosts, since it's hard to see how we could end up with a uniform idea of what keys need to be blocked. There are more issues beyond these. The easiest thing to add is surface blocking by keyid. We could then add some way of fetching from centralized registries, and any keyserver could trust any registry it chose to trust. If something is going to be added, that seems like the first thing.
I think there are two (more or less) easy solutions that should be implemented in the context of photo-IDs and and blacklisting of keys: PhotoIDs: it should be possible to switch off the delivery and display of photoIDs. This makes sure that when someone submitted offending/illegal material to my keyserver I can immediately react without shutting the whole server down. Having this feature additionally on a "by key" basis would be good in the long run. BlackListing: By introducing complex and full automatic blacklist-sync protocols we will certainly have some difficulties in agreeing on what keys to block. Possible DOS would be another case. My first interest would be a feature to block certain keys from being delivered from my keyserver. That could be a simple flag for the certain key or a blacklist file for those keys. A feature for black-list-proposals (or "semi-automatic blacklist-exchange") could be nice to ensure that we can spread the information "this key is fishy", but is not really that important (because we can easily send an email on the keyserver-malinglists). The blacklisting can be surface-blocking (this should be much easier to implement and is more the way actual keyservers work). To provide easy solutions ensures, that we have the possibilities to react real soon (TM), I prefer simple solutions now compared to complex solutions in a few years or never... ;-) Just my two cents, Olaf -- Dipl.Inform. Olaf Gellert PRESECURE (R) Consultant, Consulting GmbH Phone: (+49) 0700 / PRESECURE address@hidden
[Prev in Thread] | Current Thread | [Next in Thread] |