SKS and GnuPG related issues and possible workarounds

[Mirimir]

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.

> 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
>