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

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

Roger Dingledine:

[snip]

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

+1

Georg

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?

Thanks! David

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

Hi nusenu,

On 2021-09-10 16:05, nusenu wrote:

Thank you for working on this, I was hoping for such a flag for a long time, great to see that it is happening now.

No problem!

The flag should minimize the ability of the relay to do harm. This means such relays should _not_ be used by tor clients for _any_ other use-case than the second hop position (no HSDir, no fallbackdir, ...).

My updated proposal (most recent s7r email) says a MiddleOnly relay is strictly a middle, and nothing else. The original did not say that, and I don't know if you got the original or the most recent.

Also ensure this functionality is available to tor clients via a torrc option like "ExcludeExitNodes" can be used by tor clients as well.

The torrc option for clients could be named "LimitToMiddleOnlyNodes" or similar and takes a list of relay fingerprints and can appear multiple times in a torrc (like ExcludeExitNodes).

I don't know if torrc options are supposed to go in Proposal documents, so I excluded it from there. I will try to make sure an "ExcludeMiddleNodes" option (how I would name it) would be included, although I may do it in another ticket/MR.

If there are conflicting configurations the exclusion should overrule the inclusion of a relay fingerprint. Detected conflicts should cause a log entry. An example for a conflict: MapAddress, EntryNodes, ExitNodes (or any other including option) mentions a relay fingerprint that is also excluded.

Makes sense.

kind regards, nusenu

No problem!

-Neel

Hi,

On 2021-09-12 12:31, nusenu wrote:

Neel Chauhan:

...

...

Also ensure this functionality is available to tor clients via a torrc option like "ExcludeExitNodes" can be used by tor clients as well.

The torrc option for clients could be named "LimitToMiddleOnlyNodes" or similar and takes a list of relay fingerprints and can appear multiple times in a torrc (like ExcludeExitNodes).

I don't know if torrc options are supposed to go in Proposal documents

I agree that the naming of torrc options is not in scope of a proposal, but the fact that the MiddleOnly path selection constraint feature can be used by clients without requiring DirAuth actions probably is.

It makes sense about that. I will send an updated proposal.

...

I will try to make sure an "ExcludeMiddleNodes" option (how I would name it) would be included

A name "ExcludedMiddleNodes" would suggest the exact opposite of what MiddleOnly actually is for, no? It suggests that the given relays are excluded from the middle position but in fact they should be limited to the middle position.

Sorry, my bad.

The ExcludeMiddleNodes did give a good idea for a new feature I already have a MR for:

* https://gitlab.torproject.org/tpo/core/tor/-/issues/40466

* https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436

It's unrelated to this PR, though, and I don't know if it will go in.

kind regards, nusenu

Any time,

Neel Chauhan

Hi nusenu,

On 2021-09-12 14:47, nusenu wrote:

thanks for these pointers.

In case "ExcludeGuardNodes" option is accepted and merged, the documentation should explicitly point out the differences between

LimitToMiddleOnlyNodes NodeX vs. ExcludeGuardNodes NodeX

ExcludeExitNodes NodeX

thanks, nusenu

Makes sense. I also got confused by "LimitToMiddleOnlyNodes" versus "ExcludeMiddleNodes".

-Neel

Hi nusenu (and tor-dev@),

On 2021-09-17 16:02, nusenu wrote:

it would be great if you could open a MR for the proposal so we can always see the latest version and changes there. (Over time it became unclear what comments have already been addressed in the text an which didn't.)

Done: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/46

kind regards, nusenu

-Neel