<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 8 Jan 2016, at 04:12, Nick Mathewson <<a href="mailto:nickm@torproject.org" class="">nickm@torproject.org</a>> wrote:</div><div class=""><div class="">...<br class=""><br class="">2. Some ideas that don't work.<br class=""><br class="">...<br class=""><br class="">2.2. Blocking circuit creation under certain circumstances<br class=""><br class="">   In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option,<br class="">   and always preferring the ntor handshake where available.<br class=""><br class="">   Unfortunately, we can't simply drop all TAP handshakes, since clients<br class="">   and relays can still use them in the hidden service protocol.  But<br class="">   we could detect these versions by:<br class=""><br class="">        Looking for use of a TAP handshake from an IP not associated<br class="">        with with any known relay, or on a connection where the client<br class="">        did not authenticate.  (This could be from a bridge, but clients<br class="">        don't build circuits that go to an IntroPoint or RendPoint<br class="">        directly after a bridge.)<br class=""></div></div></blockquote><div><br class=""></div><div>I wonder how this affects existing Tor2web clients (as they make</div><div>one-hop client intro and rendezvous connections), and the</div><div>upcoming rendezvous single onion services, which make one-hop</div><div>intro and rendezvous server connections. (I also wonder about</div><div>single onion service extends, but I think they're ok.)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">   This would still result in clients not having directories, however,<br class="">   and retrying once an hours.<br class=""><br class="">3. Ideas that might work<br class=""><br class="">3.1. Move all authorities to new ports<br class=""><br class="">   We could have each authority known to older clients start listening<br class="">   for connections at a new port P. We'd forward the old port to the new<br class="">   port.  Once sufficiently many clients were using the new ports, we<br class="">   could disable the forwarding.<br class=""><br class="">   This would result in the old clients turning into zombies as above,<br class="">   but they would only be scrabbling at nonexistent ports, causing less<br class="">   load on the authorities.<br class=""><br class="">   [This proposal would probably be easiest to implement.]<br class=""></div></div></blockquote><div><br class=""></div><div>This might not work for clients that are always on:</div><div><br class=""></div><div>Changing authority ports would only affect clients that have yet to</div><div>bootstrap, or clients that are off for long enough for their consensus</div><div>to expire. Otherwise, they can continue to contact directory mirrors in</div><div>their current consensus to obtain their next consensus.</div><div><br class=""></div><div><div>For similar reasons, changing ports only works for tor versions</div><div>*without* default Fallback Directory mirrors, which likely means 0.2.7</div><div>and earlier.</div></div><div><br class=""></div><div>This might have unintended consequences:</div><div><br class=""></div><div>Some clients have FascistFirewall set, which restricts the initial</div><div>directory connection (to the authorities) to port 80. If we switched</div><div>some authorities away from DirPort 80, we'd need to switch a similar</div><div>number to DirPort 80. (Or make sure a sufficient number of default</div><div>Fallback Directory mirrors are on DirPort 80 from 0.2.8 onwards.)</div><div><br class=""></div><div>(FascistFirewall also restricts OR connections to port 443, but by the</div><div>time a client makes an OR connection, it has the full consensus.)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">3.2. Start disabling old link protocols on relays<br class=""><br class="">   We could have new relays start dropping support for the old link<br class="">   protocols, while maintaining support on the authorities and older<br class="">   relays.<br class=""><br class="">   The result here would be a degradation of older client performance<br class="">   over time.  They'd still behave zombieishly if the authorities<br class="">   dropped support, however.<br class=""></div></div></blockquote><div><br class=""></div><div>If a relay fails to support a client's protocol, does the client continue to</div><div>contact relays until it is successful?</div><div><br class=""></div><div>If so, does this place extra load on (new) relays as the proportion of new</div><div>relays increases? (Or extra load on old relays which still support the old</div><div>protocols?)</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3.3. Changing the consensus format.<br class=""><br class="">   We could allow 'f' (short for "flag") as a synonym for 's' in<br class="">   consensus documents.  Later, if we want to disable all Tor versions<br class="">   before today, we can change the consensus algorithm so that the<br class="">   consensus (or perhaps only the microdesc consensus) is spelled with<br class="">   'f' lines instead of 'f' lines.  This will create a consensus which<br class="">   older clients and relays parse as having all nodes down, which will<br class="">   make them not connect to the network at all.<br class=""><br class="">   We could similarly replace "r" with "n", or replace Running with<br class="">   Online, or so on.<br class=""><br class="">   In doing this, we could also rename fresh-until and valid-until, so<br class="">   that new clients would have the real expiration date, and old clients<br class="">   would see "this consensus never expires".  This would prevent them<br class="">   from downloading new consensuses.<br class=""><br class="">   [This proposal would result in the quietest shutdown.]<br class=""></div></div></blockquote><br class=""></div><div>Are we aiming to do this for 0.2.8?</div><div><br class=""></div><div>I think it would be a good idea, as adding default fallback directories</div><div>makes it harder to implement some authority-only strategies for</div><div>shutting down old clients.</div><div><br class=""></div><div>Tim</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="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<br class=""><br class="">teor at blah dot im<br class="">OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br class=""></body></html>