[tor-commits] [torspec/master] from Sebastian: 235-kill-named-flag.txt

[nickm at torproject.org]

commit 5f915a7148af391166291299beeb421404445eba
Author: Nick Mathewson <nickm at torproject.org>
Date:   Fri Apr 18 15:56:13 2014 -0400

    from Sebastian: 235-kill-named-flag.txt
---
 proposals/000-index.txt           |    2 ++
 proposals/235-kill-named-flag.txt |   53 +++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index dc257ae..f32d9bd 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -155,6 +155,7 @@ Proposals by number:
 232  Pluggable Transport through SOCKS proxy [OPEN]
 233  Making Tor2Web mode faster [OPEN]
 234  Adding remittance field to directory specification [OPEN]
+235  Stop assigning (and eventually supporting) the Named flag [DRAFT]
 
 
 Proposals by status:
@@ -176,6 +177,7 @@ Proposals by status:
    229  Further SOCKS5 extensions
    230  How to change RSA1024 relay identity keys [for 0.2.?]
    231  Migrating authority RSA1024 identity keys [for 0.2.?]
+   235  Stop assigning (and eventually supporting) the Named flag [for 0.2.5]
  NEEDS-REVISION:
    131  Help users to verify they are using Tor
    190  Bridge Client Authorization Based on a Shared Secret
diff --git a/proposals/235-kill-named-flag.txt b/proposals/235-kill-named-flag.txt
new file mode 100644
index 0000000..b22e7c7
--- /dev/null
+++ b/proposals/235-kill-named-flag.txt
@@ -0,0 +1,53 @@
+Filename: 235-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.