Tim Wilson-Brown - teor transcribed 19K bytes: >> On 12 Sep 2015, at 17:26, isis <isis@xxxxxxxxxxxxxx> wrote: >>> Tim Wilson-Brown - teor transcribed 23K bytes: >>>> On 10 Sep 2015, at 17:01, isis <isis@xxxxxxxxxxxxxx> wrote: >>>> >>>> 2.b. If it is useful to people, then the best way I can think of so far to >>>> keep it, but refactor it to be safer, would be to create a circuit >>>> like: >>>> >>>> Bridge â Guard â Middle â OtherMiddle â Guard â Bridge >>>> >>>> Clearly, that circuit is just a little bit insaneâ but we can't do: >>>> >>>> Bridge â Guard â Middle â Guard â Bridge >>>> >>>> because the Middle would refuse to extend back to the previous node >>>> (all ORs follow this rule). Similarly, it would be stupid to do: >>>> >>>> Bridge â Guard â Middle â OtherMiddle â Bridge >>>> >>>> because, obviously, that merely shifts the problem and accomplishes >>>> nothing. But is there something smarter I could do? >>> >>> I quite like this idea, and a 5-hop circuit is below the 8-hop limit. >> >> Okay, thanks! I'll keep this in mind as a self-testing manoeuvre we might want >> to enable for both HSes and bridges. Hopefully there's something smarter than >> "Yo! Throw some extra hops in that shit!", but if it works it works, I guess. > > Well, this is âonion" routing after allâ extra hops are the core of our anonymity > design(s). Okay, I added this part to the bridge reachability self-testing section of prop#188 earlier today. >>>> 3. Should we change how the BridgeAuthority tests Bridge ORPort reachability? >>>> If so, how? >>> >>> The bridge authority could connect via a 3-hop path, but that would suffer >>> from the same issues as bridge reachability self-testing - the bridge >>> authority extending to an ORPort not in the consensus would reveal the bridge >>> to the last hop. >>> >>> But the bridge authority could choose a set of guards (vanguards?, last-hop >>> guards?) for this purpose, reducing the chances that one is an adversary. >> >> I started thinking about this idea, but discarded it due to thinking: "Why >> expose the bridges to other nodes at all, now that we have bridge guards?" >> >> If anything, I suppose we could consider having the BridgeAuthority simply use >> its guards to connect to bridgesâ but still something feels wrong. I feel like >> this whole bridge testing system needs a giant rethinking and overhaul â rather >> than simply bolting more nodes on top of a thing which doesn't really do what >> we want anyway (i.e. testing PT reachability). > > Do you mean that the bridge authority should receive and use the bridgeâs > guards, or the bridge authorityâs guards? Sorry, I meant the BridgeAuth's guards. > If the authority already knows each bridgeâs IP and ORPort, I guess that itâs > ok for it to know the bridgeâs guards. Hrm. Perhaps it's not okay for the BridgeAuth to connect to bridges through their bridge guards? My reasoning here is that, if you're a bridge guard, we want it to look (as much as possible) like you're actually the entry guard for a normal client. Having the BridgeAuth suddenly connect to you, and ask you to connect to something you think is actually a client would look pretty weird. Thanks for the great feedback! -- ââ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev