mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-30 15:43:32 +01:00
r15533@catbus: nickm | 2007-10-04 12:30:21 -0400
Add 122-unnamed-flag.txt svn:r11762
This commit is contained in:
parent
6f7847b378
commit
9f9b729141
@ -44,6 +44,7 @@ Proposals by number:
|
|||||||
119 New PROTOCOLINFO command for controllers [CLOSED]
|
119 New PROTOCOLINFO command for controllers [CLOSED]
|
||||||
120 Suicide descriptors when Tor servers stop [OPEN]
|
120 Suicide descriptors when Tor servers stop [OPEN]
|
||||||
121 Hidden Service Authentication [OPEN]
|
121 Hidden Service Authentication [OPEN]
|
||||||
|
122 Network status entries need a new Unnamed flag [OPEN]
|
||||||
|
|
||||||
|
|
||||||
Proposals by status:
|
Proposals by status:
|
||||||
@ -59,6 +60,7 @@ Proposals by status:
|
|||||||
117 IPv6 exits
|
117 IPv6 exits
|
||||||
120 Suicide descriptors when Tor servers stop
|
120 Suicide descriptors when Tor servers stop
|
||||||
121 Hidden Service Authentication
|
121 Hidden Service Authentication
|
||||||
|
122 Network status entries need a new Unnamed flag
|
||||||
ACCEPTED:
|
ACCEPTED:
|
||||||
101 Voting on the Tor Directory System
|
101 Voting on the Tor Directory System
|
||||||
103 Splitting identity key from regularly used signing key
|
103 Splitting identity key from regularly used signing key
|
||||||
|
81
doc/spec/proposals/122-unnamed-flag.txt
Normal file
81
doc/spec/proposals/122-unnamed-flag.txt
Normal file
@ -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.
|
Loading…
Reference in New Issue
Block a user