Signature-flooded keys: current situation and mitigation

[team at schleuder.org]

Dear Schleuder admins and users,

In the last weeks the SKS keyservers that most people use to find OpenPGP-keys
have being targeted: many thousand fake signatures were added to some keys and
then uploaded to the SKS keyserver network.

GPG does not cope well with these keys. It will either refuse to import them,
or during and after the import become so slow to be effectively unusable (while
hogging CPUs). This is a potential problem for Schleuder lists, because
Schleuder by default regularly updates keys from the keyservers (in order to
receive extended expiry dates, or key revocations). Any list with an attacked
key in its keyring will become practically unusable and strain the server.

To read more details about the SKS keyservers' and GPGs problems see the links
at the bottom of this mail.

What to do?

If you have GPG processes running wild, kill them, identify the attacked key in
the keyring and delete it. This also will take a lot of time (possibly up to an
hour) but afterwards GPG will work as expected again. For help with identifying
the attacked key see https://dev.gnupg.org/T3972#127356.

Install a Schleuder update when released: We're working on a bugfix release to
ship a mitigation against these flooded keys: All third-party signatures will
be removed before a key is imported. These third-party signatures aren't really
interesting in the context of Schleuder. We will get this released and shipped
as soon as possible.

The mitigation will only work for GPG versions 2.1.15 or newer. Please upgrade
to a more recent GPG version in case yours is older! (Just to give an idea:
Both Debian stretch and buster are fine in this regard, as well as the CentOS
packages that are being available.)

Use a different keyserver: Recently keys.openpgp.org was launched. This
keyserver does not distribute third-party signatures at all.

There are downsides to using this server:

It provides most keys without User-IDs, which GPG (currently) refuses to
import. Only UserIDs whose owners (validated by email address) opted in to its
public distribution will be provided, which are (currently) not many. Thus you
will receive fewer updates from that keyserver.

X-FETCH-KEY will also not work with UserID-less keys.

It doesn't distribute key revocations: "Unfortunately, there is currently no
good way to distribute revocations that doesn't also reveal the revoked
identity itself. We don't want to distribute revoked identities, so we can't
distribute the identity at all."

It is not federated, which makes it a possible "single point of failure".

Neither of these options is a solution we are really happy with. But we
currently have nothing better to offer. Please consider yourself what suits
your setup.

In case you have any comments, question and/or feedback, please send us an
email or create a ticket in our issue tracker.

Cheers,
the schleuder dev team


---


https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
https://dkg.fifthhorseman.net/blog/community-impact-openpgp-cert-flooding.html
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e
https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2019-July/005394.html
https://blogs.gentoo.org/mgorny/2019/07/04/sks-poisoning-keys-openpgp-org-hagrid-and-other-non-solutions/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/schleuder-announce/attachments/20190717/f9d79357/attachment.sig>