[Sks-devel] Keyserver flooding attack: mitigation straw-man

[Bjarni Runar Einarsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello SKS-Devel,

Thank you for your efforts on SKS and keeping the public
keyservers running. However people may feel about the merits of
the SKS system itself, you are providing a valuable public
service.

Please forgive me if I'm stating the obvious, or raising ideas
that have been discussed to death before. However I find myself
plagued by an idea that *seems* blindingly obvious to me, but I
haven't seen discussed anywhere yet. Rather than sit on it, I
present it here for your critique.

What follows is a quick draft of a straw-man design for an opt-in
white-list based mitigation of the current flooding attacks.

Key components:

   1. A $reverse-proxy configuration which serves keys from
       disk instead of SKS, if possible
   2. A github (or gitlab, or ..,) repo containing key overrides
       and authorization statements
   3. The default pool inclusion policy requires servers use
       the $reverse-proxy config
   4. The default pool inclusion policy requires servers update
       from the repo once per $period

Assuming this is all in place, the idea is that the owner of a
key has a channel which allows them to exert control over how
their key is presented by the keyserver. The owner of a key can
request an "override" to the public git repository, which the
keyserver pools promise to implement if it is correctly signed.

So if you find your key is being flooded or spammed (or you would
for any other reason like to censor your own key), you sign an
authorization statement with that key, and then issue a pull
request against the shared git repository which adds your
authorization and the key itself to the SKS-override tree. From
that point onward, your key may still be poisoned in the raw SKS
database, but you've prevented it from being served to the
general public and you've prevented the people relying on your
key from being harmed. The cost is, from that point on you will
have to manually update your key using the above workflow instead
of SKS.

The policy of whoever manages the repository, would be to only
merge changes where the authorization statement has a valid
signature from the key owner (tooling can make this easy).

Anyone, including server admins, can hold the repository manager
to account and verify that the key owners really did authorize
the overrides (again, tooling). So this doesn't help people who
need anonymity, but it has accountability which I think would
allow us to start "censoring" which keys are served and how. If
an interface like Github is used, the public PR process also
provides accountability in case the repo admin abuses their
position to reject legitimate override requests.

Yes, it's a band-aid. But it could be implemented in just a day
or two and it would protect end-users and stop the bleeding while
the community figures out what to do about the bigger picture.

And yes, this does place the burden on the victim. It's not
perfect. But I think that is the wrong way to look at this
proposal: I propose giving the victims of flooding and poisoning
and spam attacks a way to take control, instead of being totally
helpless.

I apologise for not having presented a fully working
implementation, but I fear the community is not interested in
this sort of approach and I am reluctant to spend time working on
it until I feel there is at least some support for the idea. I
have prototyped this using nginx locally, and I'd be happy to
share my work if there is interest. But honestly I'm pretty sure
you guys are at least as qualified as I am to configure nginx,
that's not the issue here. :-)

So... what do you think, is this worth exploring further?

It's a very minor technical change, but it's a major rethink of
the current social contract around the SKS keyserver pool.

All the best,
 - Bjarni

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl0jyWwACgkQjgA3FgDP
lJEqNAf+OKmJXLH5AoT2D7oUlE1awPNrTdcANJm5zpMCi6b6+8tfiUz3b1dNSsGH
MTIa0EQbJG7ltvCS9763RofCNmrQTz6GcmhrWYwgylu9DGpgnbxyM0LaDh+WISVA
cjyJKNXEQtJE1M/RZwpXcLkZzW9nW6l07qtBe7b0xx5wveOycmg/8JOc99wMiqQb
dlk3llvOwZJF5eAQnpjQ0kRi3nEhfd/yUJ/9GhBYgmf1JjrCsYnOT6pYii+ch4FW
itqTb8VbzvF9O+pvVD+XzYxiHO2N64DVCFhOHxDMeXtoibujLphei5Mm2/9xTE/V
L1ZJ+0L+vcP1WikVwk0RMzdcA7UzZQ==
=0l1p
-----END PGP SIGNATURE-----