SKS and GnuPG related issues and possible workarounds

[Robert J. Hansen]

> a. The entire SKS keyservers design and interaction has a fundamental
> design flaw named "unlimited resources assumption". I.e., it is assumed
> every server, every client has unlimited resources (to store signatures;
> to retrieve and process them - unlimited RAM/storage, unlimited network
> speed).

This is reasonably correct.  You'll get well-intentioned pedants
screaming at you that you've got things exactly wrong (as I have
discovered in recent days), but ignore them.

> b. It is only a matter of time when other certificates are under attack.

As I understand it the current list of targeted keys is myself, dkg,
Werner, Patrick, and Kristian.  It is clear the attacker's goal is to
wedge as many GnuPG installations as possible.

> When the ones used by, say, Linux distributions to sign packages are
> affected, that will cause another wave of chaos.

Yes.  A warning is in order: few distributions use the keyserver network
to distribute signing certificates directly.  However, given the
behavior of --refresh-keys, one could always upload a poisoned signing
certificate to the keyserver network, wait for sysadmins to do a
--refresh-keys on the entire keyring, and blammo.

> So the only valid
> option is to stop using current (the one written in OCaml) keyserver
> implementation and return to stone-age practice of manually sending them.

Or switch to Autocrypt, WKD, or Hagrid.  All three options are worth
considering, although none of them are (or could be) drop-in replacements.

> c. More or less valid approach would be to
> - when exchanging with keyserver, only load/transmit signatures for
> certificates in the user's keyring. To withstand traffic and other
> resources waste, client should pass known certificates footprints first,
> to only get from a keyserver the relevant signature
> - implement local black/white lists feature - to able to filter out the
> signatures while processing them

This would only shift the problem, not cure it.  Once you poison a
certificate until it's a few gigabytes in size, you can easily kill the
entire SKS network by forcing it to reconcile that certificate over and
over.

> Am I wrong - perhaps there are brighter alternatives?

I am *cautiously* optimistic.

As an emergency mitigation, I think distributions should consider
issuing a system update that blackholes *.sks-keyservers.net, with a big
warning to people about what's happening and why.

Enigmail users are, at present, getting hit left and right due to (a)
how many of them have an affected certificate in their keyrings and (b)
Enigmail's habit of automatically refreshing keyrings.  Patrick has
already sent an emergency message to the Enigmail mailing list, and an
emergency update will be released imminently shifting to keys.openpgp.net.

Werner will no doubt be updating GpgOL as well.

Those two account for literally 99% of all use cases.  The vast majority
of OpenPGP is to verify package signatures; for the small fraction that
use it for email, Enigmail is the most dominant choice, with GpgOL a
close second.

The one small bit of silver lining to this stormcloud is we only need to
figure out how to fix three separate things.

The real damage is going to be to people's workflows.  A whole lot of
people are going to be impacted by these fixes and we can expect to need
to help an awful lot of them.