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

[brent s.]

On 05/05/2018 08:30 AM, Andrew Gallagher wrote:
> 
>> On 5 May 2018, at 11:31, brent s. <address@hidden> wrote:
>>
>> 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, 
> 
> Yes. Perhaps it would be a good idea to systematise the dump/restore process 
> so that instead of a human being following written instructions, a new peer 
> of server A will attempt to a) probe server A to find the key difference b) 
> if the difference is large, download a dump from some standard place c) 
> reinitialise itself before trying again. 
> 
> Removing human error from such processes is A Good Thing in any case...
> 
> A
> 
> 

(a) is taken care of by recon already (in a way), but the problem for
(b) is the "standard place" - SKS/recon/HKP/peering is, by nature,
unfederated/decentralized. sure, there's the SKS pool, but that
certainly isn't required for peering (even with keyservers that ARE in
the pool) nor running sks. how does one decide the "canonical" dump to
be downloaded in (b)?

i WOULD say that removing human error is good, and normally i'd totally
agree - but i think this should instead be solved in documentation, as
implementing it in the software itself seems like a lot of work that
even breaks part of SKS/peering philosophy (to me, at least) with low
payoff. i can't speak to it, but i'd be curious if anyone could
anecdotally recall how often peering requests are made to this list
without them first importing a dump.


i instead propose that:

- in the default membership file, a note should be added to the comments
at the beginning about importing a dump first for peering with
"public(?) peers" should be done (and link to one or both of [0])

- in the man page for sks, under "FILES..membership", a note be added
saying the same/similar

- in <src>/README.md, under "Setup and Configuration..### Membership
file", the same note be added


This way, there is *no possible way* a new keyserver administrator will
even know HOW to peer WITHOUT first knowing that they should use a
keydump import beforehand.


Adding in an optional refusal threshold directive (max_key_delta or
something?) for a keycount delta of more than /n/ to sks.conf
(optionally perhaps with the ability to override that value per-peer in
membership?), however, would absolutely hold value, I think.



[0] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering
    https://bitbucket.org/skskeyserver/sks-keyserver/wiki/KeydumpSources

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature