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
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel