Re: [Sks-devel] SKS apocalypse mitigation

Hi, all. There has been a lot of chatter re possible improvements to SKS on the list lately, and lots of ideas thrown around. So I thought I'd summarise the proposals here, and try to separate them out into digestible chunks. I've ordered them from less to more controversial. My personal

Re: [Sks-devel] SKS apocalypse mitigation

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

Re: [Sks-devel] SKS apocalypse mitigation

> On 5 May 2018, at 10:55, Kiss Gabor (Bitman) wrote: > > Suboptimal solutions are also acceptable. > I don't think we alwys need the best (and most expensive way). > "Almost the best" is good enough in most of practical cases. We need to define our metric to determine

Re: [Sks-devel] SKS apocalypse mitigation

> > Requests may be "iterative" or "recursive" (words are stolen from DNS). > > Users send recursive request: "I don't care how many peers > > you ask, but tell me the key with all signatures." > > The DNS has a hierarchical structure that allows the authoritative source for > data to be found

Re: [Sks-devel] SKS apocalypse mitigation

> On 5 May 2018, at 09:38, Andrew Gallagher wrote: > > >> On 5 May 2018, at 09:03, Phil Pennock wrote: >> >> While you could modify the protocol to do something like announce a >> key-count first, that's still only protection against

Re: [Sks-devel] SKS apocalypse mitigation

On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote: > > On 5 May 2018, at 08:48, Phil Pennock wrote: > > If you peer with someone with no keys > > loaded, it will render your server nearly inoperable. > > I was aware that recon would fail in this case but not that

Re: [Sks-devel] SKS apocalypse mitigation

> On 5 May 2018, at 07:00, Gabor Kiss wrote: > > Okay, brain storming in progress. :-) :-) > Requests may be "iterative" or "recursive" (words are stolen from DNS). > Users send recursive request: "I don't care how many peers > you ask, but tell me the key with all

Re: [Sks-devel] SKS apocalypse mitigation

> 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

Re: [Sks-devel] SKS apocalypse mitigation

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

Re: [Sks-devel] SKS apocalypse mitigation

> The second, harder, issue with the above is eventual consistency. > > We assume that every peer will eventually see every packet at some > point. But it is entirely possible that all of my peers will put in > place policies against (say) photo-ids, and therefore I may never see a > photo-id

Re: [Sks-devel] SKS apocalypse mitigation

Recent discussion has brought me back to thinking about Phil's suggestion again. On 25/03/18 03:37, Phil Pennock wrote: > Treat items in Filtered as part of "what we have" for reconciliation to > find the set difference. That way you never request them. Return HTTP > "410 Gone" for attempts to

Re: [Sks-devel] SKS apocalypse mitigation

> On 26 Mar 2018, at 01:39 , Michael Jones wrote: > > What if the approach was to either have a web of trust to whitelist users > able to upload images, or even more stringent strip all image data. > > Is image data essential to operating? > I’d make the case, that

Re: [Sks-devel] SKS apocalypse mitigation

What if the approach was to either have a web of trust to whitelist users able to upload images, or even more stringent strip all image data. Is image data essential to operating? I hardly ever look at the images, and these images could be shared via other means. The keyservers would continue

Re: [Sks-devel] SKS apocalypse mitigation

On 03/25/2018 07:39 AM, Andrew Gallagher wrote: > >> On 25 Mar 2018, at 03:37, Phil Pennock wrote: >> >> Disappearance of >> public keyservers would be a major inconvenience, but not a disaster. > > Considering that keyservers are currently the only resilient way to

Re: [Sks-devel] SKS apocalypse mitigation

> On 25 Mar 2018, at 03:37, Phil Pennock wrote: > > Disappearance of > public keyservers would be a major inconvenience, but not a disaster. Considering that keyservers are currently the only resilient way to distribute key revocations, I’m not sure I would be so

Re: [Sks-devel] SKS apocalypse mitigation

On 2018-03-24 at 19:01 +0100, Kristian Fiskerstrand wrote: > I agree with this as well, UAT generally have very limited value, so if > we introduce a filter to skip all UATs I'm all fine with making that a > requirement across severs in sks-keyservers.net pools. That isn't > something that

Re: [Sks-devel] SKS apocalypse mitigation

[I previously responded to a specific message not related to this thread but none the less... ] On 03/23/2018 03:02 PM, Daniel Kahn Gillmor wrote: > On Fri 2018-03-23 11:10:49 +, Andrew Gallagher wrote: >> Updating the sets on each side is outside the scope of the recon >> algorithm, and in

Re: [Sks-devel] SKS apocalypse mitigation

Hello, Horrible topic, but base64 images or something could also work for regular bank transfers. One could use the image property to store blacklist data, regular expressions, etc. That key would be a regular one but with a noisy picture. Maybe a web of DIStrust is also a good idea to vote

Re: [Sks-devel] SKS apocalypse mitigation

On Fri 2018-03-23 11:10:49 +, Andrew Gallagher wrote: > Updating the sets on each side is outside the scope of the recon > algorithm, and in SKS it proceeds by a sequence of client pull requests > to the remote server. This is important, because it opens a way to > implement object blacklists

Re: [Sks-devel] SKS apocalypse mitigation

On 23/03/18 11:10, Andrew Gallagher wrote: > Another effective method that does not require an ongoing management > process would be to blacklist all image IDs It occurs to me that this would be more wasteful of bandwidth than blocking objects by their hash, as the server would have to request

Re: [Sks-devel] SKS apocalypse mitigation

FWIW, while I'm effectively no longer involved in SKS development, I do agree that this is a problem with the underlying design, and Andrew's suggestions all sound sensible to me. On Fri, Mar 23, 2018 at 7:10 AM, Andrew Gallagher wrote: > Hi, all. > > I fear I am reheating