Matthew John Toseland <matt...@toselandcs.co.uk> writes: > On 14/09/17 17:33, Arne Babenhauserheide wrote: >> I think the core problem is that I don’t quite understand what you’re >> proposing. Bundles I understand, but I don’t understand how the scarce >> SSKs change routing. > > They don't. Pre-routing (bundles) applies to scarce SSKs as well as to > ordinary keys. What changes (in proposal 1 and later) is that during the > pre-routing phase we impose per-connection limits. > > With the updates I've posted, scarce SSKs do not get routed at all. I > don't think it makes sense to try to impose that sort of limits on > routed inserts, because it would tend to distort routing. > > Instead they only work if a key is popular. For popular keys we > generally don't route much either: the first few requests get routed, > but we end up forming a web of ULPRs, so that when the data is inserted, > it rapidly gets propagated everywhere.
It first needs to be in the store of a node at the fitting location, right? Then it gets requested and the ULPRs catch the requests. Or do the ULPRs actually see the inserts directly? > Hence my proposal is that we only allow "scarce SSKs" for keys so > popular that most of the network is subscribing to them via ULPRs. This > only means 5% or so of the network is actively requesting them > occasionally. But it covers the key use cases such as WoT announcement. So you mean when there’s a ULPR pointing to a KSK, it wouldn’t be routed? > IMHO we need a degree of fairness to provide effective spam defence. > Hence the multiple versions proposal: the spammer can insert a limited > number of keys, but he can't prevent the other legitimate inserts. This sounds like it would create much additional complexity. Do we need globally consistent CAPTCHA solutions? >> Or even deeper into my missing understanding: How should multiple SSKs >> compete at all, given that only one person has the private key? > > Announcements typically use KSKs, known private keys, or similar > spammable mechanisms. That's what we're trying to replace here. That’s great! > The only points at which this escalates to the client layer are: > 1) For proposal 2, clients will get multiple responses to a > request/subscription, and will need to decide what to do with them. > 2) For proposal 3, clients additionally should register a vote by > reinserting the SSK they prefer. -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
