Re: [Sks-devel] SKS apocalypse mitigation

[Phil Pennock]

On 2018-05-05 at 10:27 +0100, Andrew Gallagher wrote:
> Sorry for the double. We don’t need to modify the protocol to enable
> such checks. Whenever a server tries to recon with us, we can perform
> a callback against its status page and run whatever sanity tests we
> want before deciding whether to allow recon to proceed. This could be
> rolled out without any need for coordination. 

You'll need to ensure that initial_stat defaults to true and so forth
then, since by default keyservers don't calculate the stats at startup,
so such a keyserver won't be able to start peering for up to a day (3am
by default).

It's probably reasonable to change the default, but you'll want to make
this explicit when you draw up your full workflow.

Note though that the status pages are intended for humans and SKS the
keyserver can speak SKS and reconcile with other codebases, such as
Hockeypuck, which uses a different output format.  You'll probably want
to look into standardizing on something like a JSON output format, with
fallback to heuristic matching upon the output formats used by the two
current codebases.

But still my point stands: the moment you change to defaulting to
recon-open-to-everyone the scope of what counts as a security
vulnerability changes, and being open to anyone causing unbounded
computation will be a DoS security vulnerability.  With enough other
issues being tackled, I nudge once more to reconsider such a change.

-Phil