signature-flooded keys: send mail to schleuder-announce@ to inform users about the current situation and outline possible mitigation
As discussed in !291, we'll send a mail to schleuder-announce@ to inform users about the current situation in regards to signature-flooded keys and outline possible mitigation.
This is a draft for such a mail:
Subject: What's going on? Attacks? Keyservers? Certificate flooding?
Dear Schleuder users,
A few days ago, it became known that some GPG keys had being targeted: many thousand fake signatures were added to these keys, and afterwards the keys were uploaded to the SKS keyserver network.
These keyservers don't do any validation, which lead to the fact that, if fetching these keys, a local GPG installation might get "DDoSed". The sheer size of these keys will slow down GPG a lot, if not stop it altogether.
Still, the SKS keyserver network serves a quite important role, due to it being one of the main methods to distribute updates to keys, like extended expiry dates, or to publish revocations in case a key got compromised, for example.
Schleuder runs a weekly scheduled task to fetch updates of the various keyrings.
If you want to read some more details about the current situation, see the links at the bottom of this mail.
That's pretty bad.
What to do, from a Schleuder perspective?
We're in the process of finalizing a bugfix release, 3.4.1., which will 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 feature (import-filter) we're using to achieve this was introduced in GPG version 2.1.15. 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.
Recently, a new, validating keyserver was launched: keys.openpgp.org. By definition, it doesn't carry, and therefore distribute, third-party signatures. Using this keyserver, replacing the default SKS keyserver network, mitigates the problems as described above.
However, there are not only upsides, but also downsides, if using this server:
The keyserver does offer to validate the mail addresses of keys, which get uploaded, via sending a common verification email to the mail address in question.
That's an opt-in process, so there are many keys currently distributed without any mail address attached. GPG isn't able to import such keys, telling "no user ID" and exiting.
If used to fetch a key without an user ID,
x-fetch-keybreaks as well.
It probably makes sense to spread the word asking people to upload their keys and to verify their mail addresses.
By definition, the server doesn't distribute 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."
In contrast to the SKS keyserver network, this new keyserver isn't federated. It's only a single instance, it might be a "single point of failure".
Solutions might be found to all of these problems at some point in time, but that probably will take a while.
You need to decide for yourself, if changing the keyserver makes sense, or the mitigation as shipped in the upcoming version 3.4.1 are "good enough".
We're discussing about using this new keyserver as the default in Schleuder version 4.
In case you have any comments, question and/or feedback, please send us a mail or create a ticket in our issue tracker.
Cheers, the schleuder dev team