<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Sep 2015, at 17:26, isis <<a href="mailto:isis@torproject.org" class="">isis@torproject.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Tim Wilson-Brown - teor transcribed 23K bytes:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 10 Sep 2015, at 17:01, isis <<a href="mailto:isis@torproject.org" class="">isis@torproject.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">4.4.1. Bridge Reachability Self-Testing<br class=""><br class="">  Before a Bridge uploads its descriptors to the BridgeAuthority, it<br class="">  creates a special type of testing circuit which ends at itself:<br class=""><br class="">      Bob -> Guillaume -> Charlie -> Bob<br class=""><br class="">  Thus, going to all this trouble to later use loose-source routing in<br class="">  order to relay Alice's traffic through Guillaume (rather than<br class="">  connecting directly to Charlie, as Alice intended) is diminished by<br class="">  the fact that Charlie can still passively enumerate Bridges by<br class="">  waiting to be asked to connect to a node which is not<br class="">  contained within the consensus.<br class=""></blockquote></blockquote><br class="">Extending to an ORPort not in the consensus can also be used to enumerate<br class="">single onion services (prop252).  Any defences could apply to both, and if<br class="">they are indistinguishable, single onion services could provide cover for<br class="">bridges.  (Except, of course, for the defence of a single onion service being<br class="">a relay. That doesn’t help bridges.)<br class=""></blockquote><br class="">For single onion services, hiding the location/IP of the server shouldn't<br class="">matter much, since the operator has opted into less server-side anonymity.<br class="">(That is, it doesn't matter if an adversary can enumerate them, since they are<br class="">services like Facebook and Blockchain.info which have chosen to be quite<br class="">public.)<br class=""><br class="">However, for "double onion services" — or whatever we're calling the thing that<br class="">is (historical) hidden services 2.0 — your point is a good one; I'm starting to<br class="">realise more and more that defences for "double onion services"¹ are possibly<br class="">defences for bridges and vice versa.<br class=""></div></div></blockquote><div><br class=""></div><div>Except that double onion services don’t need an open ORPort at all.</div><div>Due to the rendezvous mechanism, they connect like a client, rather than like a bridge.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">   2.b. If it is useful to people, then the best way I can think of so far to<br class="">        keep it, but refactor it to be safer, would be to create a circuit<br class="">        like:<br class=""><br class="">            Bridge → Guard → Middle → OtherMiddle → Guard → Bridge<br class=""><br class="">        Clearly, that circuit is just a little bit insane… but we can't do:<br class=""><br class="">            Bridge → Guard → Middle → Guard → Bridge<br class=""><br class="">        because the Middle would refuse to extend back to the previous node<br class="">        (all ORs follow this rule).  Similarly, it would be stupid to do:<br class=""><br class="">            Bridge → Guard → Middle → OtherMiddle → Bridge<br class=""><br class="">        because, obviously, that merely shifts the problem and accomplishes<br class="">        nothing.  But is there something smarter I could do?<br class=""></blockquote><br class="">I quite like this idea, and a 5-hop circuit is below the 8-hop limit.<br class=""></blockquote><br class="">Okay, thanks!  I'll keep this in mind as a self-testing manoeuvre we might want<br class="">to enable for both HSes and bridges.  Hopefully there's something smarter than<br class="">"Yo! Throw some extra hops in that shit!", but if it works it works, I guess.<br class=""></div></div></blockquote><div><br class=""></div><div>Well, this is “onion" routing after all… extra hops are the core of our anonymity</div><div>design(s).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">3. Should we change how the BridgeAuthority tests Bridge ORPort reachability?<br class="">   If so, how?<br class=""></blockquote><br class="">The bridge authority could connect via a 3-hop path, but that would suffer<br class="">from the same issues as bridge reachability self-testing - the bridge<br class="">authority extending to an ORPort not in the consensus would reveal the bridge<br class="">to the last hop.<br class=""><br class="">But the bridge authority could choose a set of guards (vanguards?, last-hop<br class="">guards?) for this purpose, reducing the chances that one is an adversary.<br class=""></blockquote><br class="">I started thinking about this idea, but discarded it due to thinking: "Why<br class="">expose the bridges to other nodes at all, now that we have bridge guards?"<br class=""><br class="">If anything, I suppose we could consider having the BridgeAuthority simply use<br class="">its guards to connect to bridges… but still something feels wrong.  I feel like<br class="">this whole bridge testing system needs a giant rethinking and overhaul — rather<br class="">than simply bolting more nodes on top of a thing which doesn't really do what<br class="">we want anyway (i.e. testing PT reachability).<br class=""></div></div></blockquote><div><br class=""></div><div>Do you mean that the bridge authority should receive and use the bridge’s</div><div>guards, or the bridge authority’s guards?</div><div><br class=""></div><div>If the authority already knows each bridge’s IP and ORPort, I guess that it’s</div><div>ok for it to know the bridge’s guards.</div><div><br class=""></div><div>But this does seem very complicated for a design that doesn’t actually test PT</div><div>reachability (which is what we want).</div><div><br class=""></div><div>Tim (teor)</div></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Tim Wilson-Brown (teor)</div><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">teor2345 at gmail dot com<br class="">PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)<br class=""><br class="">teor at blah dot im<br class="">OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br class=""></body></html>