From 646ad49b4cc9381c55dfe083ca953366e7ddbf91 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 4 Oct 2007 16:36:53 +0000 Subject: r15533@catbus: nickm | 2007-10-04 12:30:21 -0400 Add 122-unnamed-flag.txt svn:r11762 --- proposals/122-unnamed-flag.txt | 81 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 proposals/122-unnamed-flag.txt (limited to 'proposals/122-unnamed-flag.txt') diff --git a/proposals/122-unnamed-flag.txt b/proposals/122-unnamed-flag.txt new file mode 100644 index 0000000..760d2c8 --- /dev/null +++ b/proposals/122-unnamed-flag.txt @@ -0,0 +1,81 @@ +Filename: xxx-unnamed-flag.txt +Title: Network status entries need a new Unnamed flag +Version: $Revision$ +Last-Modified: $Date$ +Author: Roger Dingledine +Created: 04-Oct-2007 +Status: Open + +Overview: + + Tor's directory authorities can give certain servers a "Named" flag + in the network-status entry, when they want to bind that nickname to + that identity key. This allows clients to specify a nickname rather + than an identity fingerprint and still be certain they're getting the + "right" server. As dir-spec.txt describes it, + + Name X is bound to identity Y if at least one binding directory lists + it, and no directory binds X to some other Y'. + + In practice, clients can refer to servers by nickname whether they are + Named or not; if they refer to nicknames that aren't Named, a complaint + shows up in the log asking them to use the identity key in the future + --- but it still works. + + The problem? Imagine a Tor server with nickname Bob. Bob and his + identity fingerprint are registered in tor26's approved-routers + file, but none of the other authorities registered him. Imagine + there are several other unregistered servers also with nickname Bob + ("the imposters"). + + While Bob is online, all is well: a) tor26 gives a Named flag to + the real one, and refuses to list the other ones; and b) the other + authorities list the imposters but don't give them a Named flag. Clients + who have all the network-statuses can compute which one is the real Bob. + + But when the real Bob disappears and his descriptor expires? tor26 + continues to refuse to list any of the imposters, and the other + authorities continue to list the imposters. Clients don't have any + idea that there exists a Named Bob, so they can ask for server Bob and + get one of the imposters. (A warning will also appear in their log, + but so what.) + +The stopgap solution: + + tor26 should start accepting and listing the imposters, but it should + assign them a new flag: "Unnamed". This would produce three cases from + the client perspective: + + 1) A unique Bob is listed as Named, and nobody lists that Bob as + Unnamed. Clients can refer to Bob by nickname and be confident. + + 2) Every Bob is listed by some authority as Unnamed. Clients asking + for Bob should get a warning in the log and their request should fail + ("no such router"). + + 3) At least one Bob is not listed by any authorities as Unnamed, but + there is no unique Named Bob. In this case we do what we did before + (currently "warn but allow it"). + +Problems not solved by this stopgap: + + If tor26 is the only authority that provides a binding for Bob, when + tor26 goes offline we're back in our previous situation -- the imposters + can be referenced with a mere ignorable warning in the client's log. + + If some other authority Names a different Bob, and tor26 goes offline, + then that other Bob becomes the unique Named Bob. + + So be it. We should try to solve these one day, but there's no clear way + to do it that doesn't destroy usability in other ways, and if we want + to get the Unnamed flag into v3 network statuses we should add it soon. + +Other benefits: + + This new flag will allow people to operate servers that happen to have + the same nickname as somebody who registered their server two years ago + and left soon after. Right now there are dozens of nicknames that are + registered on all three binding directory authorities, yet haven't been + running for years. While it's bad that these nicknames are effectively + blacklisted from the network, the really bad part is that this logic + is really unintuitive to prospective new server operators. -- cgit v1.2.3-54-g00ecf