[tor-bugs] #18332 [Tor]: Relays should store HS descriptor without the complicated "am I the right one" logic (was: Relay should store HS descriptor even when they don't have the HSDir flag)

[Tor Bug Tracker & Wiki]

#18332: Relays should store HS descriptor without the complicated "am I the right
one" logic
----------------------+------------------------------------
 Reporter:  dgoulet   |          Owner:
     Type:  defect    |         Status:  new
 Priority:  Medium    |      Milestone:  Tor: 0.2.9.x-final
Component:  Tor       |        Version:
 Severity:  Normal    |     Resolution:
 Keywords:  tor-hs    |  Actual Points:
Parent ID:            |         Points:  small
  Sponsor:  SponsorR  |
----------------------+------------------------------------

Old description:

> This maybe sounds crazy but the idea here is that service and HSDir can
> have
> different view of the network so it's possible that a service thinks some
> relay
> is an HSDir but not the relay itself resulting in a failure to upload the
> descriptor (good thing we have 6 hsdirs!). Also, it would be useful in
> our
> figth against malicious HSDir enumerating .onion, we could find them
> before
> they actually become an HSDir.
>
> As long as the relay sees that it's responsible for the descriptor ID, it
> should store it with or without the HSDir flag. Being responsible for the
> descID is important here else we can end up lowering the bar for anyone
> to
> upload arbitrary data enclosed in a descriptor. Altough this is possible
> right
> now, let's not make it possible for _all_ relays at _all_ time for _any_
> ID.
>
> As for DoS consideration that is someone uploading lots and lots of
> descriptors
> in the first 96 hours before becoming an HSDir, then oops the relay is
> out of
> memory for legitimate descriptors. First, we currently have this
> "problem" and
> second we do purge our cache if memory usage goes to high (part of our
> oom).
>
> We should NOT cache it when `supports_tunnelled_dir_requests` is unset.
> It's a
> requirement to become an HSDir that if we don't have we shouldn't do it.
> (`DirCache 0` or `ClientOnly` or `DirPort` set, ...)
>
> Thoughts?

New description:

 Right now relays try to guess if they have the HSDir flag, and try to
 guess if they are the right HSDir for the descriptor to be uploaded, and
 they refuse the descriptor if they think they weren't supposed to receive
 it.

 This behavior is ripe for consistency bugs, since maybe clients correctly
 have a different view of the network than the hsdir does, so it refuses a
 descriptor when it isn't supposed to refuse it.

 It also generally adds complexity to hsdir behavior, which doesn't need to
 be there.

 Now, there is one argument for refusing hidserv descriptors when you don't
 think you'll be asked for them by clients -- it makes it a little bit
 harder to use relays to store arbitrary data blobs (since you need to
 arrange for the data blobs to have content such that they are supposed to
 go to that hsdir for that day). But I don't think this barrier is any real
 barrier to somebody trying to stuff a relay with descriptors. I think
 defending against that DoS or misuse attack is worth exploring, but I
 don't think the current behavior represents a good tradeoff.

--

Comment (by arma):

 (I am hijacking David's ticket, with permission.)

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