[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Hi,

I have an updated proposal.

On 2021-09-07 13:52, s7r wrote:

Don't worry -- it's glad to have you back always. Thanks. No judging
anywhere around here by any means :)


No problem!


The proposal looks much better with the motivation section, at least
me know what's all about.


Thanks!


So the DirAuths will just vote about MiddleOnly like they vote about
BadExit, based on internal communication. Sounds plausible for the
desired goal.


Makes sense


I saw you mentioned on the list of position where we will NOT use
MiddleOnly relays RendezVous Points. Please add a note to it that in
order to enforce this particular requirement, we need to teach the
onion service server that receives the INTRODUCE2 cell to a rend point
with MiddleOnly flag to not proceed with the rend protocol and close
that circuit. Otherwise the requirement enforcement won't work because
anybody doing any attack would probably use modified clients that
don't follow the rules to not select a MiddleOnly as rend point.


I've added that section.


I don't see any major blockers for this proposal, because if it's
voted at DirAuth level only, in case it makes troubles for us in a
perfect future (walking onions / all exits) we can simply decide at
DirAuth level to not vote on it any more and remove the code that
parses it.


Makes sense.
Although being a realist here, all exits aren't likely, mainly for relays hosted on residential ISPs as well as hosts less supportive of exit relays. But hey, we never know, we should prepare for any scenario, good or bad.
Both are very common. The former IMHO is very good as it helps decentralize/diversify the network away from big datacenters, even if only for non-exits. It's harder to surveil every ISP in NA and EU than it it to surveil a few OVH, Scaleway, and Hetzner datacenters. However the latter still sucks period, all hosts should allow exits.
For me, I'd love to have an exit from home, but there are too many blockers in that. My home middle relay is off right now mainly because of severe ping spikes when it's on [1]. 


What will the consensus requirement be for this flag? 50%+1? IIRC the
BadExit flag can be assigned with less than 50%+1 DirAuths.
To stay safe from malicious relays, like BadExit, my updated proposal says that if one dirauth gives a relay the MiddleOnly flag, then it's set for that relay. This is to prevent harm while all (or the majority of) dirauths give the relay that flag. 

-Neel

Tidbits if you're interested (feel free to ignore if you aren't):
[1] - The CenturyLink tech said they need to add capacity to the neighborhood's GPON splitter node. And no, I'm not signing up for Comcast since Tor+WFH would saturate the DOCSIS upstream assuming I won't go over the cap (which I will).
Filename: 334-middle-only-flag.txt
Title: A dirauth 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.

  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

   * Exit

   * Onion Service Rendevous Point

   * Onion Service Intro Point

   * Onion Service HSDir

   * Fallback Directories

  The reason for this is to prevent a misconfigured relay from being used
  in places where they may know about the client directly. This is in case
  certain misconfigured relays are used to deanonymize clients.

4. Onion Service Implementation

  As MiddleOnly relays are not used as rendezvous points, we will need special
  considerations on onion service hosts.

  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.

5. Consensus Considerations

5.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.

5.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.

  This is to help prevent a malicious relay from harming the network while
  the majority of dirauths' administrators wait to give the said relay a
  MiddleOnly flag.

6. Citations

  [1] - https://gitlab.torproject.org/tpo/core/tor/-/issues/40448

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev