SKS and GnuPG related issues and possible workarounds

[Michał Górny]

Dnia July 3, 2019 6:23:37 AM UTC, Mirimir via Gnupg-users <gnupg-users at gnupg.org> napisał(a):
>On 07/02/2019 08:28 PM, Konstantin Boyandin via Gnupg-users wrote:
>> Hello All,
>> 
>> After having read the recent multitude of messages related to SKS
>> keyservers related issue, I figured out that
>> 
>> 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).
>
>Either that, or it's the assumption that people won't do bad things.
>That was apparently a common assumption, back in the day.
>
>> b. It is only a matter of time when other certificates are under
>attack.
>> When the ones used by, say, Linux distributions to sign packages are
>> affected, that will cause another wave of chaos. 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.
>
>Yes. I gather that people working on really key stuff have likely been
>very aware of this issue, perhaps for years, and are protected. But
>there are probably many who were/are unaware, and are vulnerable.
>
>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.

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

>
>> 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
>
>I doubt that solutions depending on client behavior could ever work.
>
>> d. The above, or any other approach is hard to implement in
>foreseeable
>> future, even harder to make a de facto standard.
>
>It doesn't need to be a new standard. People have been working or that
>for years, and there's been much progress. But apparently there's
>nothing yet that satisfies all use cases.
>
>> Personally, I am mostly concerned with b. at the moment. And if
>approach
>> "data came, data stay" remains in effect for keyservers, they will
>> merrily be flooded with junk certificates/signatures. I can see no
>easy
>> means to prevent that, without wasting resources of human users.
>
>Same here about b. But from what little I know about SKS keyservers,
>"data came, data stay" ain't gonna change. So they'll just need to
>handle the junk. But it's arguably good enough if they can not serve
>junk to client apps that can't handle it.
>
>> Am I wrong - perhaps there are brighter alternatives?
>> 
>> Thanks.
>> 
>> Sincerely,
>> Konstantin Boyandin
>> 
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>> 
>
>_______________________________________________
>Gnupg-users mailing list
>Gnupg-users at gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-users

(I'm replying from phone, sorry about lack of line wrapping and uncut quote)
--
Best regards, 
Michał Górny