[tor-bugs] #11743 [Tor]: nodelist_add_microdesc: assign md to all appropriate nodes properly

[Tor Bug Tracker & Wiki]

#11743: nodelist_add_microdesc: assign md to all appropriate nodes properly
-----------------------------+--------------------------------------
     Reporter:  cypherpunks  |      Owner:
         Type:  defect       |     Status:  new
     Priority:  major        |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay needs-proposal
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------------
Changes (by nickm):

 * priority:  normal => major
 * keywords:   => tor-relay needs-proposal
 * milestone:   => Tor: 0.2.5.x-final


Comment:

 Hm. There are a lot of options here.  Let's find the best one we can do
 quickly, and then the best one to do long-term.

 '''(A)''' Proposal 228 ('''cross-certify identity keys with onion keys''')
 would help here somewhat, but in 0.2.5 we would still need a way for
 authorities to enforce uniqueness on microdescriptors, since proposal 228
 isn't even implemented yet, much less deployed to all routers.

 '''(B)''' Probably the best way to prevent md hash duplication would be to
 this would be to add a new consensus algorithm to '''add a distinguisher
 to any microdescriptors'''. Adding a short hash of the identity key to all
 microdescriptors (say, 128 bits, since we're worried about preimages and
 not collisions) would be adequate there.

 '''(C)''' One thing that ''isn't'' easy to do would be '''adding the
 distinguisher only when two microdescriptors would collide'''.  But that
 isn't easy, since we might not know that they will collide until all the
 votes are in.  (Consider what happens if n/2+1 of the authorities vote for
 router A, and n/2+1 vote for router B, and both routers have the same
 microdescriptors, but .)

 '''(D)''' We can also, as a stopgap, '''refuse to vote for two routers
 with the same onion key''', if we have a reasonably good way to be sure
 that we are voting for the right router.

 '''(E)''' Another way would be to '''reject any router that uses the same
 onion key as another router''' if we can't build circuits through it,
 though I don't know if the authorities' testing mechanisms currently try
 circuit building.

 '''(F)''' A final fix here would be to '''fix all the client code''' to
 allow multiple nodes to share a microdescriptor.  I don't think that's a
 great idea for 0.2.5, since the code there might be fragile.  I'm not sure
 it's a good idea for 0.2.6 either, since nodes really ''shouldn't'' share
 microdescriptors.

 So my inclination here is to do (B) and/or (D) in Tor 0.2.5, and (A) in
 Tor 0.2.6.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11743#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online