> On 28 Oct 2015, at 14:31, Virgil Griffith <i@xxxxxxxxx> wrote: > > Instead of WOT, it seems more desirable, and better fit diversity, to have both your best friends and worst enemies on the same circuit. Ergo, minimizing chance of collaboration. Like Tails' friends, foes, and neutral HTP poolsâ "any member in a one pool should be unlikely to share logs (or other identifying data), or to agree to send fake time information, with a member from the the other pools" https://tails.boum.org/contribute/design/Time_syncing/#index4h2 <https://tails.boum.org/contribute/design/Time_syncing/#index4h2> T > > -V > On Mon, 26 Oct 2015 at 01:30 grarpamp <grarpamp@xxxxxxxxx <mailto:grarpamp@xxxxxxxxx>> wrote: > On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had: > > I agree with Roger that ideally all relays can be exits (and since > > we're being ideal, we'll assume that 'exit' means to every port). And > > the network location distribution of relays by bandwidth is > > proportional to both the client destination selection over time and > > general Internet traffic over time, which match each other since we're > > being ideal, and also matter since we're using an ideal trust-aware path > > selection algorithm. And network wide route selection is such that > > there is no congestion (generalizing Roger's assumption of infinite > > exit capacity). > > Guessing that... assuming you can ship and calculate all the relay > data / DHT / weights / KEX / circuits / preferences without > bogging down your network or cpu... > > More relays being exits yields higher maximum possible path diversity. > More relays being exits yields higher potential aggregate throughput > between the network and clearnet. > More exits yields broader more complete location overlay relavent to > users (more relays yields more guards), datacenteres, and clearnet > services (though there's as yet no attempt to exit near a service > unless done manually). > > However when subject to global passive adversary tapping > lots of the fiber, and you turn up more relays as exits (which > are also non-exit relays by nature), you're adding lots more > unused bandwidth over the same current consumption, leading > to lots of unused quiet portions of the network. > Which seems a greater potential for the adversary to "look, user > just shot a unique traffic pattern completely through the quiet > zone, gotcha". > Whereas when the network links are full with clocked traffic > (and fill traffic if there would otherwise be slack space) that > observation attack is hardly as possible, to relavently impossible. > > If true, it seems to me adding more [non] exits should be pegged to > some metrics and solicited on need / planning rather than turning > up 6000 exits all at once. > > > In our ongoing work on trust-aware path selection, we assume a trust > > distribution that will be the default used by a Tor client if another > > distribution is not specified. (Most users will not have a reasoned > > understanding of who they actually need to worry most about, and even > > if they somehow got that right would not have a good handle how that > > adversary's resources are distributed.) We call this adversary "The > > Man", who is equally likely to be everywhere (each AS) on the > > network. For relay adversaries, we assume that standing up and running > > a relay has costs so weight a bit to make relays that have been around > > a long time slightly more likely to be trusted. > > tor-relays had talk of individual humans keyparty signing their relays > and including that WOT along with other trust and meta metrics > in the consensus or other queryable datastore that could be used > by the user to select preferred relay sets in whichever sensible or > silly ways suited them. > > An adversary standing up relays has costs. > Adversaries standing their human agents in public, even if > their undercover is maintained, has additional costs and risks. > > > You > > would then be faced with the political nightmare of issuing default > > policies that tells users they should route with a weighting that says > > country foo has an x percent chance of being your adversary, but > > country bar has a y percent chance. (Likewise also have similar > > statements that substitute 'large multinational corp.', 'major > > criminal organization', 'specific big government agency that is > > getting all the press lately' etc. for "country" in the last > > sentence.) > > ======== > In a sense this is like the original 'valid' flag, which you got > by mailing me and having me manually approve your relay (and without > which you would never be used as the entry or exit point in a circuit). > Periodically I wonder if we should go back to a design like that, where > users won't pick exit relays that don't have the "socially connected" > badge. Then I opt against wanting it, since I worry that we'd lose > exactly the kind of diversity we need most, by cutting out the relays > whose operators we don't know. > > But both sides of that are just guessing. Let's find out! > ======== > > > These type of things may be better suited to a system > where the users contribute their research and knowledge > about the network into the network metadata db, and the > users can query it to make their own decisions, follow > other users prebuilt selection templates, or stick > with the provided defaults. > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk