shipping with fallbackdir sources
Hi, so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet. Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important. At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list. We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time. I have written a script to come up with a list of notes that match our criteria. It's currently at https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates It currently produces https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list Discuss :) -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
Hi Peter, On 4/17/15, Peter Palfrader <weasel@torproject.org> wrote:
Hi,
so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time.
Is there a way to make the Tor Dir Auths produce that file as a verifiable consensus every hour? Or is there a way to make the client set that list of constraints and then we can just use a normal consensus file?
I have written a script to come up with a list of notes that match our criteria. It's currently at https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates
It currently produces https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list
That seems reasonable and I think that it is better than nothing. I worry that the process is too manual. All the best, Jacob
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
On 4/17/15, Peter Palfrader <weasel@torproject.org> wrote:
so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time.
Is there a way to make the Tor Dir Auths produce that file as a verifiable consensus every hour? Or is there a way to make the client set that list of constraints and then we can just use a normal consensus file?
I think this list would be created at release time and ship with the tor binaries/source. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
On 4/17/15, Peter Palfrader <weasel@torproject.org> wrote:
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
On 4/17/15, Peter Palfrader <weasel@torproject.org> wrote:
so, Tor has included a feature to fetch the initial consensus from nodes other than the authorities for a while now. We just haven't shipped a list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places where clients can find the consensus is that it makes authority reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address, and port for a while now (120 days), and have been running, a guard, and a v2 directory mirror for most of that time.
Is there a way to make the Tor Dir Auths produce that file as a verifiable consensus every hour? Or is there a way to make the client set that list of constraints and then we can just use a normal consensus file?
I think this list would be created at release time and ship with the tor binaries/source.
That gives a build person a lot of power - should we expect each distro to do it correctly? I trust that you will do a fine job but I'm not sure about others... It gives an attacker an opportunity to segment or partition a view of the network, I think. If the document is a strict signed subset produced by the current Dir Auths, I think we'd not have that concern. All the best, Jake
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
I think this list would be created at release time and ship with the tor binaries/source.
That gives a build person a lot of power - should we expect each distro to do it correctly? I trust that you will do a fine job but I'm not sure about others...
We could expect Nick or Roger to do it correctly when they make Tor releases. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
On Fri, Apr 17, 2015 at 08:37:23PM +0200, Peter Palfrader wrote:
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
I think this list would be created at release time and ship with the tor binaries/source.
That gives a build person a lot of power - should we expect each distro to do it correctly? I trust that you will do a fine job but I'm not sure about others...
We could expect Nick or Roger to do it correctly when they make Tor releases.
Jake, Remember that the purpose is to help first-time clients, who have never used the Tor network before, fetch their very first consensus. To do that, they'll need addresses to contact bundled into the binary and/or distro without being able to look at a consensus first.
On 4/17/15, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Fri, Apr 17, 2015 at 08:37:23PM +0200, Peter Palfrader wrote:
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
I think this list would be created at release time and ship with the tor binaries/source.
That gives a build person a lot of power - should we expect each distro to do it correctly? I trust that you will do a fine job but I'm not sure about others...
We could expect Nick or Roger to do it correctly when they make Tor releases.
If it ships in a Tor release, we can assume all other packagers will pass that onward, of course. Still, it could be tampered with if it doesn't have dir auth signatures. I can imagine a friendly packager thinking it would be useful to add their own router, for example.
Remember that the purpose is to help first-time clients, who have never used the Tor network before, fetch their very first consensus. To do that, they'll need addresses to contact bundled into the binary and/or distro without being able to look at a consensus first.
Of course - I'm merely suggesting that the file shipped is somehow a regular byproduct of the network rather than the result of a one off script run at an arbitrary time. However it is produced, I think it would be good to track each of these documents once they're shipped as well. I guess it could be done in git as part of the release process. All the best, Jake
On Fri, 17 Apr 2015, Jacob Appelbaum wrote:
On 4/17/15, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
Remember that the purpose is to help first-time clients, who have never used the Tor network before, fetch their very first consensus. To do that, they'll need addresses to contact bundled into the binary and/or distro without being able to look at a consensus first.
Of course - I'm merely suggesting that the file shipped is somehow a regular byproduct of the network rather than the result of a one off script run at an arbitrary time.
It currently looks at past behavior of nodes. However, it still is the case that when you and I run it at different times we'd get different lists.
However it is produced, I think it would be good to track each of these documents once they're shipped as well. I guess it could be done in git as part of the release process.
I was picturing the list be treated similar to the geoip database we ship at tor. Before release, it gets updated in git and then is part of the source. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `- http://www.debian.org/
participants (3)
-
Ian Goldberg -
Jacob Appelbaum -
Peter Palfrader