SKS and GnuPG related issues and possible workarounds

[Mirimir]

On 07/02/2019 11:42 PM, Michał Górny wrote:
> Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users <gnupg-users at gnupg.org> napisał(a):

<SNIP>

>> I don't think that it's necessary to stop using SKS keyservers. And I
>> suspect that doing so would be nontrivial. Given that requests to them
>> are likely hard-coded, or buried in obscure options and preferences.
>> Stuff that nobody has touched for years.
>>
>> I believe that the most practical approach is 1) efficiently finding
>> toxic keys, and 2) reconfiguring keyservers not to serve them. I get
>> that many find this distasteful, doing the attackers' work for them,
>> etc, etc, etc. But it would limit damage, to the extent that toxic keys
>> can be identified soon enough. And there are other ways to share good
>> copies of those keys. Via Keybase, for example. Or as you say,
>> manually.
> 
> I don't think this is going to work long term. Even if you manage to 
> somehow synchronously control all servers in SKS rotation, there's no 
> way to prevent attackers from poisoning them over and over again.

I'm not suggesting any controls on a server-by-server basis. I'm
suggesting that blacklisting of toxic keys be a software update. And as
the Tor network does, keyservers would ignore peers running outdated
versions.

Also, if what I propose is workable, toxic keys won't matter. They'll
just be wasted space on the keyservers. And indeed, "poisoning them over
and over again" isn't at all an issue. Given that toxic keys, or the
signatures that poison them, can't actually be removed. By design, to
prevent censorship.

> Then, they may decide to start mass poisoning other keys just to 
> prove this is not the right solution.

If what I propose is workable, attackers can poison as many keys as they
like. Until SKS keyservers go down, anyway. Until then, if the system
catches them quickly enough, they won't do widespread damage. They'll
inconvenience some people, of course, but that seems unavoidable. And as
an extra benefit, this would nuke file systems that store data in
signatures.

<SNIP>