Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote:
> > On 5 May 2018, at 08:48, Phil Pennock <address@hidden> wrote:
> > If you peer with someone with no keys
> > loaded, it will render your server nearly inoperable.
> 
> I was aware that recon would fail in this case but not that the failure mode 
> would be so catastrophic. Is there no test for key difference before recon is 
> attempted?

It's the calculation of the key difference which is the problem.  That's
what recon is.

Recon figures out the difference in the keys present.  It's highly
efficient for reasonable deltas in key counts.  Yaron Minskey wrote
papers on the topic, leading to his academic degree; they're linked
from:
  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home

After recon figures out what the local server needs, it then requests
those keys using HKP.

While you could modify the protocol to do something like announce a
key-count first, that's still only protection against accidental
misconfiguration: worthwhile and a nice-to-have if there's ever an
incompatible protocol upgrade anyway, to have a safety auto-cutoff to
back up the manual checks people do, but not protection against malice.

Fundamentally, reconciliation between datasets requires computation.
You can add safety cut-offs, and rate-limits per IP and CPU limits per
request and various other things, but none of those help if you're
trying to protect the keyservers from a half of the apocalypse
scenarios.

-Phil