[Sks-devel] Dumps/importing & de-peering (WAS: Re: SKS apocalypse mitigation)

[brent s.]

On 05/05/2018 03:48 AM, Phil Pennock wrote:
> On 2018-05-04 at 17:13 +0100, Andrew Gallagher wrote:
>> 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 SKS reconciliation algorithm scales with the count of the
> differences in key-counts.  If you peer with someone with no keys
> loaded, it will render your server nearly inoperable.
> 
> We've seen this failure mode before.  Repeatedly.  It's part of why I
> wrote the initial Peering wiki document.  It's why I walked people
> through showing how many keys they have loaded, and is why peering is so
> much easier these days: most people who post to sks-devel follow the
> guidance and take the hints, and get things sorted out before they post.

indeed; i'm with phil on this. the importing process is integral to the
turnup, which is why i offer keydumps[0] myself (available via both http
and rsync, compressed - maybe FTP someday as well), and offer
instructions in that section. and why i wrote this query tool[1]. and
this dumping script[2]. and packaged this[3].

(thanks, phil, by the way for those instructions. i found them super
helpful when i first turned up. and thanks to whomever it was on IRC(?)
that gave me the brilliant idea of running a modified second SKS
instance locally for no-downtime dumps!)

one of the key (no pun intended) criteria i have for peering is their
delta for # of keys off from mine. (i should add in a delta/comparison
function to [1] at some point. hrmmm...)

it is SO IMPORTANT for both ends of the peering to have a relatively
recent keyset. i don't see how we can "fix" this without entirely
restructuring how HKP recon behaves, which is no easy task from my
understanding (should it be even necessary first - i don't believe it
requires "fixing", personally).

> 
> This is why we only peer with people we whitelist, and why most people
> look for as much demonstration of Clue as they can get before peering,
> and it's a large part of why we do see de-peering when actions
> demonstrate a lack of trustworthiness.

relevant to this point, i'm still relatively new to keyserver
administration and this list - is there a sort of established procedure
or policy for "announcing" a peer that individuals should de-peer with
(should they be peering with said peer)? what incident response policy
should one follow? what criteria/actions would lead to suggested de-peering?


i diverted the thread because i feel we're crossing into off-topic with
those questions i had and i don't want to hijack the original topic,
since it seems to still be under consideration.



[0] http://mirror.square-r00t.net/#dumps
[1] https://git.square-r00t.net/OpTools/tree/gpg/keystats.py
[2] https://git.square-r00t.net/OpTools/tree/gpg/sksdump.py
[3] https://aur.archlinux.org/packages/sks-local/

-- 
brent "i said 'peer(ing|ed|)' too many times in this email" saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature