Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
> ``` > Filename: 335-middle-only-redux.md > Title: An authority-only design for MiddleOnly > Author: Nick Mathewson > Created: 2021-10-08 > Status: Open > ... > > These flags SHOULD be set in a vote whenever `MiddleOnly` is > present, and only when the authority is configured to vote on the > `BadExit` flag. > > * `BadExit` > > These flags SHOULD be cleared in a vote whenever `MiddleOnly` is > present. > > * `Exit` I believe that BadExit is supposed to be given together with Exit, to mark that technically it's possible to exit from this relay, but it is not recommended unless you know what you do. > * `Guard` > * `HSDir` > * `V2Dir` It looks like we don't fear such a relay at Intro? Or it is a sign that this proposal is only a set of quick actions before #334? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
On Sun, Oct 10, 2021 at 12:39 PM nusenu wrote: > > Hi, > > has this proposal any implications wrt to making the MiddleOnly > feature available to clients (without requiring DA actions)? > > With ExcludeExitNodes/ExitNodes + ExcludeGuardNodes [1] > tor clients basically can get the "MiddleOnly" feature without DA actions, > but ExcludeGuardNodes [1] is not there yet. This is why I'm asking. > > [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436 I don't think it would especially help or prevent a MiddleOnly/ExcludeGuard feature for clients. > > ## Generating votes > > > > When voting for a relay with the `MiddleOnly` flag, an authority > > should set all flags indicating that a relay is unusable for a > > particular purpose, and against all flags indicating that the relay > > is usable for a particular position. > > This part was not clear to me, but if I ignore it, the rest makes sense. > It is not clear because it says an authority should set _all_ flags to > indicate > that a relay is unusable for a particular purpose. Ooops, that should say that the authority should vote for all "this relay is unusable" flags, and against all "this relay is usable for a non-middle purpose" flags. I'll edit. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
Hi, has this proposal any implications wrt to making the MiddleOnly feature available to clients (without requiring DA actions)? With ExcludeExitNodes/ExitNodes + ExcludeGuardNodes [1] tor clients basically can get the "MiddleOnly" feature without DA actions, but ExcludeGuardNodes [1] is not there yet. This is why I'm asking. [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436 ## Generating votes When voting for a relay with the `MiddleOnly` flag, an authority should set all flags indicating that a relay is unusable for a particular purpose, and against all flags indicating that the relay is usable for a particular position. This part was not clear to me, but if I ignore it, the rest makes sense. It is not clear because it says an authority should set _all_ flags to indicate that a relay is unusable for a particular purpose. kind regards, nusenu -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 335: An authority-only design for MiddleOnly
``` Filename: 335-middle-only-redux.md Title: An authority-only design for MiddleOnly Author: Nick Mathewson Created: 2021-10-08 Status: Open ``` # Introduction This proposal describes an alternative design for a `MiddleOnly` flag. Instead of making changes at the client level, it adds a little increased complexity at the directory authority's voting process. In return for that complexity, this design will work without additional changes required from Tor clients. For additional motivation and discussion see proposal 334 by Neel Chauhan, and the related discussions on tor-dev. # Protocol changes ## Generating votes When voting for a relay with the `MiddleOnly` flag, an authority should set all flags indicating that a relay is unusable for a particular purpose, and against all flags indicating that the relay is usable for a particular position. These flags SHOULD be set in a vote whenever `MiddleOnly` is present, and only when the authority is configured to vote on the `BadExit` flag. * `BadExit` These flags SHOULD be cleared in a vote whenever `MiddleOnly` is present. * `Exit` * `Guard` * `HSDir` * `V2Dir` ## Computing a consensus This proposal will introduce a new consensus method (probably 32). Whenever computing a consensus using that consensus method or later, authorities post-process the set of flags that appear in the consensus after flag voting takes place, by applying the same rule as above. That is, with this consensus method, the authorities first compute the presence or absence of each flag on each relay as usual. Then, if the `MiddleOnly` flag is present, the authorities set `BadExit`, and clear `Exit`, `Guard`, `HSDir`, and `V2Dir`. # Configuring authorities We'll need a means for configuring which relays will receive this flag. For now, we'll just reuse the same mechanism as `AuthDirReject` and `AuthDirBadExit`: a set of torrc configuration lines listing relays by address. We'll call this `AuthDirMiddleOnly`. We'll also add an `AuthDirListsMiddleOnly` option to turn on or off voting on this option at all. # Notes on safety and migration Under this design, the MiddleOnly option becomes useful immediately, since authorities that use it will stop voting for certain additional options for MiddleOnly relays without waiting for the other authorities. We don't need to worry about a single authority setting MiddleOnly unilaterally for all relays, since the MiddleOnly flag will have no special effect until most authorities have upgraded to the new consensus method. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
