Re: [Sks-devel] SKS apocalypse mitigation

[Andrew Gallagher]

On 03/05/18 20:18, Gabor Kiss wrote:
>
> Just a historical note.
> Folks, have you noticed the similarity between distribution of
> keys and newsfeed? ("News" was very popular communication form
> before forums, web2 and high speed internet access.[1])
> News admins had to search "good" partners if they wanted to get a rich
> subset of newsgroups.
> On the top of evolution of news servers you can find INN with a lot of
> sophisticated solutions.
> Fraction of experiences of decades of news may be useful here too.

Yes, but this was driven by the limitations of pre-ARPAnet networking,
where you couldn't assume that you could connect directly to an
arbitrary news server. The same limitations also resulted in bang-path
email routing.

But email has long since migrated to a direct-connection delivery
paradigm, and for good reason. Sure, the idea that absolutely anybody
can set up a mail server and start opening connections to yours is a
little scary if you're not used to it. But that's how any internet
service works.

AFAICT, the limitation that SKS servers should only recon with known
peers was introduced as a measure against abuse. But it's a pretty
flimsy anti-abuse system considering that anyone can submit or search
for anything over the HKP interface without restriction.

I think all SKS servers should attempt to recon with as many other
servers as they can find. The tools exist to walk the network from a
known starting point or points and enumerate all responsive hosts. Why
not have each SKS server walk the network and update the in-memory copy
of its membership on an ongoing basis? If a previously unknown server
does try to recon, what's the harm? So long as it recons successfully it
should go into the list with all the rest.

That way the membership file as it exists now is just a starting point,
like the DNS root hints. No more begging on the list for peers. Just
pre-seed your membership file with a selection of the most stable SKS
sites (e.g. the ones coloured blue on the pool status page) and within
an hour you're peering with the entire pool, and them with you.

If any SKS server is found to be abusing trust, then block away. But
let's permit by default and block specific abuse rather than the other
way around. There may be a need for rate-limiting recon at some point,
but I don't think the pool is anywhere near that big yet.

-- 
Andrew Gallagher

signature.asc
Description: OpenPGP digital signature