[tor-dev] Proposal 334: A flag to mark Relays as middle-only

[Neel Chauhan]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 334-middle-only-flag.txt
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20210914/87b96c64/attachment.txt>