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

Wed Sep 15 07:48:30 UTC 2021

David Goulet:
> On 14 Sep (11:31:02), Neel Chauhan wrote:
>> Hi Roger,
> 
> Hi Neel!
> 
> Thanks for your proposal!!
> 
>>
>> 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
> 
>> Filename: 334-middle-only-flag.txt
>> Title: A Directory Authority flag to mark Relays as Middle-only
>> Author: Neel Chauhan
>> Created: 2021-09-07
>> Status: Open
>>
>> 1. Introduction
>>
>>   The Health Team often deals with a large number of relays with an incorrect
>>   configuration (e.g. not all relays in MyFamily), or needs validation that
>>   requires contacting the relay operator. It is desirable to put the said
>>   relays in a less powerful position, such as a middle only flag that prevents
>>   a relay from being used in more powerful positions like an entry guard or an
>>   exit relay. [1]
>>
>> 1.1. Motivation
>>
>>   The proposed middle-only flag is needed by the Health Team to prevent
>>   misconfigured relays from being used in positions capable of deanonymizing
>>   users while the team evaluates the relay's risk to the network. An example
>>   of this scenario is when a guard and exit relay run by the same operator
>>   has an incomplete MyFamily, and the same operator's guard and exit are used
>>   in a circuit.
>>
>>   The reason why we won't play with the Guard and Exit flags or weights to
>>   achieve the same goal is because even if we were to reduce the guard and
>>   exit weights of a misconfigured relay, it could keep some users at risk of
>>   deanonymization. Even a small fraction of users at risk of deanonymization
>>   isn't something we should aim for.
>>
>>   One case we could look out for is if all relays are exit relays (unlikely),
>>   or if walking onions are working on the current Tor network. This proposal
>>   should not affect those scenarios, but we should watch out for these cases.
>>
>> 2. The MiddleOnly Flag
>>
>>   We propose a consensus flag MiddleOnly. As mentioned earlier, relays will be
>>   assigned this flag from the directory authorities.
>>
>>   What this flag does is that a relay must not be used as an entry guard or
>>   exit relay. This is to prevent issues with a misconfigured relay as described
>>   in Section 1 (Introduction) while the Health Team assesses the risk with the
>>   relay.
>>
>> 3. Implementation details
>>
>>   The MiddleOnly flag can be assigned to relays whose IP addresses are
>>   configured at the directory authority level, similar to how the BadExit flag
>>   currently works. In short, if a relay's IP is designated as middle-only, it
>>   must assign the MiddleOnly flag, otherwise we must not assign it.
> 
> Note: a unique identifier of relays is by relay identity key (its
> fingerprint), not the IP address. However, it is true we do reject relays
> based on fingerprint and address most of the times so I think it would be
> better to also specify the fingerprint approach as well.
> 
>>
>>   Relays which haven't gotten the Guard or Exit flags yet but have IP addresses
>>   that aren't designated as middle-only in the dirauths must not get the
>>   MiddleOnly flag. This is to allow new entry guards and exit relays to enter
>>   the Tor network, while giving relay administrators flexibility to increase
>>   and reduce bandwidth, or change their exit policy.
>>
>> 3.1. Client Implementation
>>
>>   Clients should interpret the MiddleOnly flag while parsing relay descriptors
>>   to determine whether a relay is to be avoided for non-middle purposes. If
>>   a client parses the MiddleOnly flag, it must not use MiddleOnly-designated
>>   relays as entry guards or exit relays.
>>
>> 3.2. MiddleOnly Relay Purposes
>>
>>   If a relay has the MiddleOnly flag, we do not allow it to be used for the
>>   following purposes:
>>
>>    * Entry Guard
>>
>>    * Directory Guard
>>
>>    * Exit Relay
>>
>>   The reason for this is to prevent a misconfigured relay from being used
>>   in places where they may know about clients or destination traffic. This
>>   is in case certain misconfigured relays are used to deanonymize clients.
>>
>>   We could also bar a MiddleOnly relay from other purposes such as rendezvous
>>   and fallback directory purposes. However, while more secure in theory, this
>>   adds unnecessary complexity to the Tor design and has the possibility of
>>   breaking clients that aren't MiddleOnly-aware [2].
> 
> Can we have a note on why HSDir, Intro and Rendezvous relays have not been put
> in that list?
> 
>>
>> 4. Consensus Considerations
>>
>> 4.1. Consensus Methods
>>
>>   We propose a new consensus method 32, which is to only use this flag if and
>>   when all authorities understand the flag and agree on it. This is because the
>>   MiddleOnly flag impacts path selection for clients.
>>
>> 4.2. Consensus Requirements
>>
>>   On the directory authorities, similar to the BadExit flag, if one dirauth
>>   gives a relay the MiddleOnly flag, we should mark the MiddleOnly flag for
>>   the relay even if other dirauths didn't add the flag.
> 
> I'm a tiny bit skeptical about this here. This is a whole lot of power for one
> dirauth.
> 
> The idea behind enforcing a consensus method is that a majority of authorities
> would vote on MiddleOnly and not very few.
> 
> It is true that there is often a delay with a majority of authorities agreeing
> on a flag from the time the health team flag a relay MiddleOnly.
> 
> However, I'm not sure we should always let 1 authority dictate that flag
> regardless of what the others think.
> 
> It is _not_ common but it had happened in the past that TPO's health team
> would recommend to reject a relay and few authorities agreed to do it but not
> the majority as the rest didn't find the reasons good enough and so the relay
> was never rejected in the end because lack of majority.
> 
> That is a bit the last last safe guard of the authority protocol here which is
> that an actual trusted operators makes the ultimate decision to reject or not
> based on the information provided by the health team. And this works if every
> decision needs majority.
> 
> Adding that requirement would not allow this and so like rejecting a relay
> from the consensus, I think we need to enforce majority here and not have one
> single authority dictate it.
> 
> Thoughts?

Yes, I agree with that reasoning. I don't think the delay in proposing
relay X is getting the MiddleOnly flag and a majority of directory
authorities saying so is an issue. It's not an issue either in the
outright reject cases where we find an actual attacker, which are
arguably worse. And even if it really were an issue, we could ping folks
to apply the flag in case we actually find its application urgent.

Additionally, and to pick up the second potential argument you mention,
those directory authorities that were in the past reluctant to reject a
bunch of relays (for good reasons) that got proposed by network health
folks might now be pretty happy with applying the MiddleOnly flag (for
the same reasons).

Georg

> Thanks!
> David
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20210915/953ca599/attachment-0001.sig>