Proposal idea: Stop assigning (and eventually supporting) the Named flag
Filename: xxx-kill-named-flag.txt Title: Stop assigning (and eventually supporting) the Named flag Authors: Sebastian Hahnn Created: 10 April 2014 Target: 0.2.5 Status: Draft 1. Intro and motivation Currently, Tor supports the concept of linking a Tor relay's nickname to its identity key. This happens automatically as a new relay joins the network with a unique nickname, and keeps it for a while. To indicate that a nickname is linked to the presented identity, the directory authorities vote on a Named flag for all relays where they have such a link. Not all directory authorities are currently doing this - in fact, there are only two, gabelmoo and tor26. For a long time, we've been telling everyone to not rely on relay nicknames, even if the Named flag is assigned. This has two reasons: First off, it adds another trust requirement on the directory authorities, and secondly naming may change over time as relays go offline for substantial amounts of time. Now that a significant portion of the network is required to rotate their identity keys, few relays will keep their Named flag. We should use this chance to stop assigning Named flags. 2. Design None. Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard. 3. Implementation The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise. Once this has been shown to not cause any issues, support for the Named flag can be removed from the Tor client implementation, and support for the NamingAuthoritativeDirectory can be removed from the Tor directory authority implementation. 4. Open questions None.
On 10/04/14 09:45, Sebastian Hahn wrote:
Filename: xxx-kill-named-flag.txt Title: Stop assigning (and eventually supporting) the Named flag Authors: Sebastian Hahnn Created: 10 April 2014 Target: 0.2.5 Status: Draft
1. Intro and motivation
Currently, Tor supports the concept of linking a Tor relay's nickname to its identity key. This happens automatically as a new relay joins the network with a unique nickname, and keeps it for a while. To indicate that a nickname is linked to the presented identity, the directory authorities vote on a Named flag for all relays where they have such a link. Not all directory authorities are currently doing this - in fact, there are only two, gabelmoo and tor26.
For a long time, we've been telling everyone to not rely on relay nicknames, even if the Named flag is assigned. This has two reasons: First off, it adds another trust requirement on the directory authorities, and secondly naming may change over time as relays go offline for substantial amounts of time.
Now that a significant portion of the network is required to rotate their identity keys, few relays will keep their Named flag. We should use this chance to stop assigning Named flags.
If I understand the proposal correctly, operators will still be able to name their relay or bridge, and people can still find it in Atlas or Globe by this nickname. If so, great!
2. Design
None. Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard.
3. Implementation
The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise.
What's the process here? "Ask on tor-dev@ if anybody sees a problem if the Named and Unnamed flags go away, wait for a week, and then just do it?" All the best, Karsten
Once this has been shown to not cause any issues, support for the Named flag can be removed from the Tor client implementation, and support for the NamingAuthoritativeDirectory can be removed from the Tor directory authority implementation.
4. Open questions
None.
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 18 Apr 2014, at 15:02, Karsten Loesing <karsten@torproject.org> wrote:
If I understand the proposal correctly, operators will still be able to name their relay or bridge, and people can still find it in Atlas or Globe by this nickname. If so, great!
Yes, this is in no way related to the nickname field.
The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise.
What's the process here?
"Ask on tor-dev@ if anybody sees a problem if the Named and Unnamed flags go away, wait for a week, and then just do it?"
I don't know, I want to move gabelmoo to a new machine and don't really want to set up the naming system. So I guess the above process as soon as possible :) Cheers Sebastian
On Thu, Apr 10, 2014 at 3:45 AM, Sebastian Hahn <hahn.seb@web.de> wrote:
2. Design
None. Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard.
Imo we _should_ check through the code for things related to the Named flag, though, back through 0.2.3 or maybe 0.2.2. Reasons: * Private networks never worked very well with older tors. * Maybe there's some piece of obscure functionality that breaks without naming authorities which we never tested on a private network. -- Nick
On 18 Apr 2014, at 19:52, Nick Mathewson <nickm@alum.mit.edu> wrote:
Imo we _should_ check through the code for things related to the Named flag, though, back through 0.2.3 or maybe 0.2.2. Reasons:
* Private networks never worked very well with older tors. * Maybe there's some piece of obscure functionality that breaks without naming authorities which we never tested on a private network.
Ok, here's round two then, with the Design section updated: Filename: xxx-kill-named-flag.txt Title: Stop assigning (and eventually supporting) the Named flag Authors: Sebastian Hahnn Created: 10 April 2014 Target: 0.2.5 Status: Draft 1. Intro and motivation Currently, Tor supports the concept of linking a Tor relay's nickname to its identity key. This happens automatically as a new relay joins the network with a unique nickname, and keeps it for a while. To indicate that a nickname is linked to the presented identity, the directory authorities vote on a Named flag for all relays where they have such a link. Not all directory authorities are currently doing this - in fact, there are only two, gabelmoo and tor26. For a long time, we've been telling everyone to not rely on relay nicknames, even if the Named flag is assigned. This has two reasons: First off, it adds another trust requirement on the directory authorities, and secondly naming may change over time as relays go offline for substantial amounts of time. Now that a significant portion of the network is required to rotate their identity keys, few relays will keep their Named flag. We should use this chance to stop assigning Named flags. 2. Design None so far, but we should review older-but-still-supported Tor versions (down to 0.2.2.x) for potential issues. In theory, Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard, but we're unsure if there might be some functionality that isn't typically tested with private networks and could get broken now. 3. Implementation The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise. Once this has been shown to not cause any issues, support for the Named flag can be removed from the Tor client implementation, and support for the NamingAuthoritativeDirectory can be removed from the Tor directory authority implementation. 4. Open questions None.
On Fri, Apr 18, 2014 at 2:29 PM, Sebastian Hahn <hahn.seb@web.de> wrote:
On 18 Apr 2014, at 19:52, Nick Mathewson <nickm@alum.mit.edu> wrote:
Imo we _should_ check through the code for things related to the Named flag, though, back through 0.2.3 or maybe 0.2.2. Reasons:
* Private networks never worked very well with older tors. * Maybe there's some piece of obscure functionality that breaks without naming authorities which we never tested on a private network.
Ok, here's round two then, with the Design section updated:
Filename: xxx-kill-named-flag.txt
Thanks! I've added this as proposal 235.
On 18 Apr 2014, at 21:56, Nick Mathewson <nickm@alum.mit.edu> wrote:
Thanks! I've added this as proposal 235.
Code review down to 0.2.3.x has shown that the naming-related code hasn't changed much at all, and no issues were found which would mean a Named-flag free consensus would cause any problems. gabelmoo and tor26 have stopped acting as Naming Directory Authorities, and - pending any issues - will stay that way. For now, the two will continue to collect naming-related statistics to ensure we can turn it back on in case any trouble is identified. Cheers Sebastian
participants (3)
-
Karsten Loesing -
Nick Mathewson -
Sebastian Hahn