Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

Todd Fleisher
FYI

Begin forwarded message:

Subject: Signature-flooded keys: current situation and mitigation
Date: July 17, 2019 at 1:07:19 PM PDT


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/


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

Andrew Gallagher

> On 18 Jul 2019, at 17:46, Todd Fleisher <[hidden email]> wrote:
>
> "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."

We can kill two birds with one stone here, using two simple extensions-by-convention of the protocol.

A key owner can (preferably automatically) create a “self-identity” on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using “fpr:00000000000000000000000000000000000”, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info.

A recipient can then infer from revocation of the self-identity that the primary key itself has been revoked (and by extension all associated identities, whether published or not).

A

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

SKS Devel mailing list
Hi Andrew,

On 18.07.2019 19:35, Andrew Gallagher wrote:
> A key owner can (preferably automatically) create a “self-identity” on her primary key consisting of a well-known string that contains no personal information. To avoid breaking legacy search-by-id systems this string should be unique to the primary key. I suggest using “fpr:00000000000000000000000000000000000”, where the zeros are replaced by the fingerprint of the key. The self-identity (and any revocations on it) can then be safely distributed by keystores that would otherwise refuse to distribute personal info.

Minor thing: I suggest using
"openpgp4fpr:00000000000000000000000000000000000" instead of "fpr".
That'd make the User ID a valid URI as "openpgp4fpr" is an assigned URI
Scheme, see:

https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Probably the cleanest solution (suggested by others) would be using
direct key signature (0x1F) [0] and avoid User IDs entirely. Your
suggestion Andrew has the benefit that it's immediately backwards
compatible with software "in the wild".

[0]: https://tools.ietf.org/html/rfc4880#section-5.2.1

Kind regards,
Wiktor


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (907 bytes) Download Attachment