On 14/09/17 17:33, Arne Babenhauserheide wrote: > > Matthew John Toseland <matt...@toselandcs.co.uk> writes: >> On 13/09/17 21:23, Arne Babenhauserheide wrote: >>> Matthew John Toseland <matt...@toselandcs.co.uk> writes: >>>> Proposal 0: Bundles >>>> ------------------- >>> Do I understand it correctly that this means that all inserts from a >>> given source initially travel along the same path? >> Right, this is the poor man's tunneling scheme. Although one day perhaps >> we could have something like PISCES. > > Poor mans tunneling (=simplest tunneling which could work) sounds like > something pretty useful. > >>> It would be great to have this for requests, too, since this would >>> clearly stop most correlation attacks which are used right now. > … >>>> Proposal 1: Scarce SSKs with global (per-node) scarcity >>>> ------------------------------------------------------- >>> … >>>> Proposal 2: Scarce SSKs with per-key scarcity and multiple versions >>>> ------------------------------------------------------------------- >>> … >>>> Proposal 3: Scarce SSKs with voting >>>> ----------------------------------- >>> … >>> I don’t really understand these three. They all sound like they could >>> leak information from the anonymous ID layer to the networking layer. >> >> I don't see why. Maybe you can make an argument re voting schemes. But >> what is wrong with proposal 1 that makes it any different security-wise >> to what happens now? > > 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. 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. For new apps which might take time to get that popular, we will need to provide an API which will smoothly fallback from one to the other. > My reason to worry is that when something on the content layer (for > example pseudonyms) affects routing, it can be detected from routing > performance. Do you want to provide spam defense, or do you want to > provide some kind of fairness? 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. > > 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. Although it would equally work with PSKs... but maybe we don't need the complexity of PSKs with the voting proposal. 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. > > Best wishes, > Arne
signature.asc
Description: OpenPGP digital signature
