Proposal: Let us run a keyserver

[Phil Pennock]

On 2020-03-07 at 17:15 +0100, Bernhard Reiter wrote:
> When looking at https://sks-keyservers.net/status/
> we see only three Tor and four hkps servers.
> 
> So what about rending a server and running a keyserver as e.V.?
> (Depending on what it takes, maybe we can find someone to sponsor the 
> administration time necessary. Does someone know how much admin time it would 
> take?)

I ran a keyserver for about 8 years, I wrote most of the operational
documentation and debugged a lot of problems for people.

Most of the time, the operational overhead was minimal.  Until it
wasn't, as people started deliberately trying to destroy the keyserver
network.

There are folks who think that the keyserver network should not exist,
so they sponsor (EFF) or directly develop (others) tools to destroy it,
to prove their point and push an agenda of one of the other crypto
ecosystem tools.

(If you take venture capitalist money, you need there to not be free
alternatives which are better than what you're selling; if those
alternatives are vulnerable to attack, well ... sooner or later, one of
those companies is going to be less ethical than the others.)

> What do you think?
> Is this a good use of our resources?

The keyserver network is a public append-only filesystem.  This is not
compatible with strong privacy law.  The first keyserver to be hit by
this was Peter Palfrader's, about the time I first got involved, a
decade ago, when an Austrian filed a take-down notice to remove their
"personal details" (name and email address) and Mr Palfrader decided
that his only option, short of fighting a losing legal battle, was to
shut down.

I'm now American and my reaction to people gloating about how the GDPR
would make the keyservers impossible was to move my keyserver to the
USA.  But then people released tools to make it easy to encode images
and store them across a bunch of keys and signatures.  At which point,
we're looking at the legal implications of what DKG in his
abuse-resistant keystore draft calls "toxic data" -- a *very* good name
for it.

I think that the public keyservers fulfilled a social need for a long
time, but that their time has passed.  I think that their existence
provided a crutch which kept us from developing alternatives which
properly protect participants.  The toxic swamp that is the collection
of keys in the public keyservers has undermined faith in OpenPGP as
people persist in trying to find ways to avoid needing to bother with
trusted introduction and the web-of-trust.

One time, I had to turn on request logging to debug an operational
problem.  More than 50% of requests were for one key, relating to the
MongoDB if I recall correctly, and asking around this was not a new
state of affairs.  The reward system of the public keyservers is broken;
it's not supporting individuals as much as it's supporting sloppy build
systems and businesses which try to externalize as many costs as
possible, no matter how much it costs others.

I think that the Verein's resources are better spent pushing
next-generation keyserving facilities.  The WKD stuff is good, a better
UI on it might help.  Abuse resistant keystores would be good.

Migration strategies to help wean people off their addiction to the
public keyservers would be good.

Perhaps guest blog posts from people who work on infrastructure for
various projects, writing about their experiences setting up key
handling for their projects?

 * Debian is using WKD; how, what was involved in setting it up?
 * Gentoo is using WKD and stuff in human web-pages; what is the
   infrastructure behind this, how can others replicate it?
 * kernel.org has WKD and a git repo with keys for the Linux kernel
   maintainers; I would welcome articles by Konstantin Ryabitsev talking
   about his experiences herding cats here.

Even without WKS, WKD provides a nice stable predictable naming
convention for federated HTTPS-based key access.  What might be good is
some kind of optional update notification standard for WKD, so that
people can register interest to get push notifications via webhooks or
something else when there's an update.

A pubsub system which tracks updates to WKD via those updates and
maintains an anonymising layer so that domain operators don't get to see
all the people interested in keys, with TOR gateways and other such
facilities, might be something worth exploring; it could support more
than WKD, but would stick to the idea that someone is accountable for
any key present and keys can disappear over time.

Heck, if the notification can include the full key as part of the
payload, you could auto-ingest the keys directly without needing to
connect back (but it would require signing the payloads with a shared
secret to prevent injection attacks); that gets you closer to being able
to recreate something like the SKS network, if you want.


There are many options for how the GnuPG Verein should expend its
resources.  I assert that trying to resurrect the SKS network is a case
of living in the past when we should be trying to build the future.

The future the Verein supports should be one without gatekeepers who can
extract rents, but one which is still accountable and isn't designed to
require that people host toxic data in an all-or-nothing proposition.

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/verein/attachments/20200307/00250bf3/attachment.sig>