[tor-dev] Proposal 334: A flag to mark Relays as middle-only
neel at neelc.org
Tue Sep 14 18:31:02 UTC 2021
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
>> 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
> Tor's design will change over time and we'll forget to update this
>> On an onion service host, when a INTRODUCE2 cell is received, if the
>> rendevous point has a MiddleOnly flag, the onion service host should
>> 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
> 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
> flag, but your Tor thinks it does (e.g. because I have the consensus
> 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
> 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
> 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
> on what is an acceptable rendezvous point would be weird.
> That is, I think these extra restrictions (avoiding the relays) would
> a slight improvement to security in theory, but I see that as
> by the loss of robustness and by the other security angle (avoiding
> letting people probe our internal network knowledge).
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the tor-dev