[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 which addresses your concerns, along with
David Goulet's comments on GitLab.
On 2021-09-07 12:47, s7r wrote:
Hi Neel,
Please add a "MOTIVATION" section and explain in detail why is this
needed for the network/heath team and how will it improve things? Also
include in the "MOTIVATION" section the following:
- Why not play with the Exit/Guard to achieve the same goal, why not
possible? what is the goal -- we need to know the goal to further
discuss this.
I have an updated proposal which addresses your concerns, along with
David Goulet's comments on GitLab.
- It's something at Directory Authority Level only? So the client /
relay operator has no decision whatsoever for this flag? What are the
tie breakers or based on what is this assigned?
This is something assigned at the dirauth-level.
- How will this work in a wonderful feature I am dreaming of where all
the relays are Exits and maybe we make walking onions working?
I believe it shouldn't affect these scenarios, but have mentioned we
should look out for them.
P.S. Rendezvous point is NOT a less powerful position (at least from
an onion service server/operator point of view), unless you are using
vanguards plugin by Mike with rendguard component activated. Because
it's always chosen by the client connecting to the onion service, and
we should assume the client is always ~LE~ evil. Trust me on this :)
I have also updated this to be a strictly Middle-only flag, and am not
giving rendezvous capabilities to MiddleOnly relays.
Sorry about this, but I have taken more-or-less a so-called "break" from
Tor development for a while. I am technically a volunteer, and my
$DAYJOB is at "Big Tech" (don't judge, that's where I found work).
I also got FreeBSD "commit bit" (not every Tor developer uses Debian)
which took time away from Tor volunteer efforts. I am only getting back
to Tor development as of the past week or two, so I need to refresh my
memory.
Going back, this update also completes the missing paragraph reported by
Ian, that seemed to miss me in the original proposal.
-Neel Chauhan
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. Consensus Method
We also 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. 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