Hi Roger,
On 2021-09-12 20:48, Roger Dingledine wrote:
On Sun, Sep 12, 2021 at 12:17:37PM -0700, Neel Chauhan wrote:
If a relay has the MiddleOnly flag, we do not allow it to be used for the following purposes:
- Entry Guard
While we're trying to be exhaustive here, "Directory Guard" might be a good addition to this list. (But trying to be exhaustive is risky because Tor's design will change over time and we'll forget to update this list.)
On an onion service host, when a INTRODUCE2 cell is received, if the rendevous point has a MiddleOnly flag, the onion service host should close the circuit and therefore not proceed with the protocol.
Two thoughts on this part:
(A) If we're teaching Tors to actively avoid touching these MiddleOnly relays even when other people specify them, the rendezvous point isn't the only one to look for. The next one that comes to mind is the introduction point, i.e. if a client gets an onion descriptor that lists an introduction point that has the flag, they would want to avoid it. And now that we've got two examples, I bet there's a third, and even if there isn't a third now, it's the sort of thing where future design changes will forget to consider this part.
(B) There's a bigger problem here, stemming from desynchronized network knowledge. For example, if my Tor doesn't think a relay has the MiddleOnly flag, but your Tor thinks it does (e.g. because I have the consensus from this hour and you have the one from last hour), then you'll refuse to interact with me.
First, this situation can leak to me which consensus you're using, which could build into other attacks. See this classic paper on this risk: https://www.freehaven.net/anonbib/#danezis-pet2008
And second, this situation introduces hard-to-debug robustness issues, which wouldn't be just a theoretical concern, since they would happen each time the flag transitions on a given relay.
My suggestion would be to drop this idea of having Tors refuse to use MiddleOnly relays in risky roles when other people specify them. We already make sure to build our own path using relays we wanted to use, before reaching those risky roles. Let's trust the other side to do it too and not worry about it if it doesn't.
In the case of the two examples we've identified so far, the attacker could use any relay they like in the next hop after that relay, and we wouldn't know whether they're doing it. And for the rendezvous point case in particular, it doesn't even need to be a relay that's in the consensus right now (in part because we didn't want to get into the information desync situation there too), so putting only this constraint on what is an acceptable rendezvous point would be weird.
That is, I think these extra restrictions (avoiding the relays) would be a slight improvement to security in theory, but I see that as outweighed by the loss of robustness and by the other security angle (avoiding letting people probe our internal network knowledge).
--Roger
Roger and George, thank you so much for your feedback.
I was worried restricting MiddleOnly relays too far would become too ambitious and hard to implement a la Windows "Longhorn"/Vista (disclaimer: I work at Microsoft but not on Windows). I guess it's true.
I have an updated Prop334 attached.
-Neel