Re: [Sks-devel] Blacklisting Keys

[Olaf Gellert]

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 the
>         key.  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