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

[Neel Chauhan]

Hi David,

On 2021-09-14 12:00, David Goulet wrote:
> On 14 Sep (11:31:02), Neel Chauhan wrote:
>> 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.

IMHO there are two sides to the coin.

If a malicious relay is MiddleOnly'd by its fignerprint, it could rekey 
and possibly become an guard/exit again.

However, a malicious relay operator could also change IPs (e.g. cloud) 
while keeping the fingerprint the same.

However, my updated proposal adds the fingerprint section.

>>   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?

I believe Roger sent me a writeup where it would add a lot of complexity 
to the tor code: 
https://lists.torproject.org/pipermail/tor-dev/2021-September/014627.html

I can agree with him, would we want another Windows "Longhorn"/Vista and 
get something so mired in complexity?

>> 
>> 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?

The majority system does sound good to me.

> Thanks!
> David

I have an updated proposal with your suggestions, but will read

Sorry if I couldn't get back to you earlier. Yesterday, my team at 
$DAYJOB decided to go back to the office, and outside of work hours, I 
have been wrangling with a fiber ISP with massive latency spikes which 
prevents me from running a Tor relay at home.

No problem,

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/20210917/704642fc/attachment.txt>