Hi Roger,
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.
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].
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.
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.
5. Acknowledgements
Thank you so much to nusenu, s7r, and Roger Dingledine for your suggestions
to Prop334. My proposal wouldn't be what it is without you.
6. Citations
[1] - https://gitlab.torproject.org/tpo/core/tor/-/issues/40448
[2] -
https://lists.torproject.org/pipermail/tor-dev/2021-September/014627.html
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
