On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote: > > On 5 May 2018, at 08:48, Phil Pennock <sks-devel-p...@spodhuis.org> 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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel