Neel Chauhan wrote:
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.
Don't worry -- it's glad to have you back always. Thanks. No judging anywhere around here by any means :)
The proposal looks much better with the motivation section, at least me know what's all about.
So the DirAuths will just vote about MiddleOnly like they vote about BadExit, based on internal communication. Sounds plausible for the desired goal.
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 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.
What will the consensus requirement be for this flag? 50%+1? IIRC the BadExit flag can be assigned with less than 50%+1 DirAuths.
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev