On 14/09/17 22:18, Arne Babenhauserheide wrote: > > 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.
No. > > Or do the ULPRs actually see the inserts directly? ULPRs are Ultra-Lightweight Passive Requests. What that means is that they are *waiting for the data to be inserted/found*. Once the data is found, we rapidly propagate it to the entire network. So if the data has been inserted already, there is no need for ULPRs, and it can be found within a hop or two of just about any node. The other side of this mechanism is "RecentlyFailed": if we get a request for a key, and the same node has recently requested it (with some other conditions I don't remember), we terminate the request, because we are effectively already looking for it. Because of ULPRs, if we see the data, it will be forwarded to the node that requested it. Put together, we radically reduce traffic generated by things like WoT, allowing them to subscribe to keys but only actively poll them every 10 minutes or so, while propagating popular data so quickly that FLIP has sub-minute latencies. > >> 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? Popular keys don't get routed. The first few requests get routed but pretty soon we are rejecting requests with RecentlyFailed. Periodically a few more requests are let through. Inserts *do* currently get routed, even for popular keys: we forward them as normal, and then only start triggering the ULPRs once the insert has run out of HTL and been stored. But this is a security tradeoff. And ULPRs are not just useful for globally important keys; they can be a useful optimisation if only part of the network is polling for the key, forming a tree routed where the data should be stored. But for scarce SSK inserts, we are assuming that only popular keys matter. This mechanism is purely for things like WoT announcements, where there's a good chance that 1/HTL of the network is polling for them. Specifically, the process for a scarce *insert* will be: 1) Is the key popular?? We can tell this from how many peers are subscribed to it in the ULPR table. If not, kill the request; we only provide protection for popular applications. 2) Has there been another scarce SSK insert from the same peer recently? If so, kill the request; they've used their quota. (More complex conditions are possible; quotas, per-key etc) 3) Commit the data to the datastore and propagate it via ULPRs. So indeed, there is no routing involved here. > >> 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? We're trying to eliminate the need for CAPTCHAs here, because they have poor security *and* poor usability, and are basically unsustainable. We could use them as well, but any serious attacker will certainly be able to solve CAPTCHAs cheaply, while they are a PITA for many users, especially disabled users. All we do is have a single global Scarce KSK queue for announcements. Every WoT instance subscribes to it. The key is generated from the date and changes e.g. once a day. All scarce inserts are propagated to all nodes - but the scarcity mechanism restricts the number of inserts. Spammers tend to be contained in a small area of the network, though they may cause some local damage, but if that becomes a problem there are probably solutions we could think about. Every WoT instance adds every identity announced via the queue. Then we rely on the usual mechanisms to weed out spammers after the fact - some combination of positive and negative trust, backed by the fact that it's relatively costly to create new identities. This is the WoT use case. I still think there are others, but this is the most urgent one. Also I'm assuming proposal 2, i.e. multiple versions. We could do it with proposal 1, but it turns into a series of races, less friendly to people joining throughout the day etc, and possibly more vulnerable to capture by spammers. > >>> 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. >
signature.asc
Description: OpenPGP digital signature
