122-unnamed-flag.txt 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117
  1. Filename: 122-unnamed-flag.txt
  2. Title: Network status entries need a new Unnamed flag
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Roger Dingledine
  6. Created: 04-Oct-2007
  7. Status: Open
  8. 1. Overview:
  9. Tor's directory authorities can give certain servers a "Named" flag
  10. in the network-status entry, when they want to bind that nickname to
  11. that identity key. This allows clients to specify a nickname rather
  12. than an identity fingerprint and still be certain they're getting the
  13. "right" server. As dir-spec.txt describes it,
  14. Name X is bound to identity Y if at least one binding directory lists
  15. it, and no directory binds X to some other Y'.
  16. In practice, clients can refer to servers by nickname whether they are
  17. Named or not; if they refer to nicknames that aren't Named, a complaint
  18. shows up in the log asking them to use the identity key in the future
  19. --- but it still works.
  20. The problem? Imagine a Tor server with nickname Bob. Bob and his
  21. identity fingerprint are registered in tor26's approved-routers
  22. file, but none of the other authorities registered him. Imagine
  23. there are several other unregistered servers also with nickname Bob
  24. ("the imposters").
  25. While Bob is online, all is well: a) tor26 gives a Named flag to
  26. the real one, and refuses to list the other ones; and b) the other
  27. authorities list the imposters but don't give them a Named flag. Clients
  28. who have all the network-statuses can compute which one is the real Bob.
  29. But when the real Bob disappears and his descriptor expires? tor26
  30. continues to refuse to list any of the imposters, and the other
  31. authorities continue to list the imposters. Clients don't have any
  32. idea that there exists a Named Bob, so they can ask for server Bob and
  33. get one of the imposters. (A warning will also appear in their log,
  34. but so what.)
  35. 2. The stopgap solution:
  36. tor26 should start accepting and listing the imposters, but it should
  37. assign them a new flag: "Unnamed".
  38. This would produce three cases in terms of assigning flags in the consensus
  39. networkstatus:
  40. i) a router gets the Named flag in the v3 networkstatus if
  41. a) it's the only router with that nickname that has the Named flag
  42. out of all the votes, and
  43. b) no vote lists it as Unnamed
  44. else,
  45. ii) a router gets the Unnamed flag if
  46. a) some vote lists a different router with that nickname as Named, or
  47. b) at least one vote lists it as Unnamed, or
  48. c) there are other routers with the same nickname that are Unnamed
  49. else,
  50. iii) the router neither gets a Named nor an Unnamed flag.
  51. (This whole proposal is meant only for v3 dir flags; we shouldn't try
  52. to backport it to the v2 dir world.)
  53. Then client behavior is:
  54. a) If there's a Bob with a Named flag, pick that one.
  55. else b) If the Bobs don't have the Unnamed flag (notice that they should
  56. either all have it, or none), pick one of them and warn.
  57. else c) They all have the Unnamed flag -- no router found.
  58. 3. Problems not solved by this stopgap:
  59. 3.1. Naming authorities can go offline.
  60. If tor26 is the only authority that provides a binding for Bob, when
  61. tor26 goes offline we're back in our previous situation -- the imposters
  62. can be referenced with a mere ignorable warning in the client's log.
  63. If some other authority Names a different Bob, and tor26 goes offline,
  64. then that other Bob becomes the unique Named Bob.
  65. So be it. We should try to solve these one day, but there's no clear way
  66. to do it that doesn't destroy usability in other ways, and if we want
  67. to get the Unnamed flag into v3 network statuses we should add it soon.
  68. 3.2. V3 dir spec magnifies brief discrepancies.
  69. Another point to notice is if tor26 names Bob(1), doesn't know about
  70. Bob(2), but moria lists Bob(2). Then Bob(2) doesn't get an Unnamed flag
  71. even if it should (and Bob(1) is not around).
  72. Right now, in v2 dirs, the case where an authority doesn't know about
  73. a server but the other authorities do know is rare. That's because
  74. authorities periodically ask for other networkstatuses and then fetch
  75. descriptors that are missing.
  76. With v3, if that window occurs at the wrong time, it is extended for the
  77. entire period. We could solve this by making the voting more complex,
  78. but that doesn't seem worth it.
  79. [3.3. Tor26 is only one tor26.
  80. We need more naming authorities, possibly with some kind of auto-naming
  81. feature. This is out-of-scope for this proposal -NM]
  82. 4. Other benefits:
  83. This new flag will allow people to operate servers that happen to have
  84. the same nickname as somebody who registered their server two years ago
  85. and left soon after. Right now there are dozens of nicknames that are
  86. registered on all three binding directory authorities, yet haven't been
  87. running for years. While it's bad that these nicknames are effectively
  88. blacklisted from the network, the really bad part is that this logic
  89. is really unintuitive to prospective new server operators.