Send tor-dev mailing list submissions to
 tor-dev@lists.torproject.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
or, via email, send a message with subject or body 'help' to
 tor-dev-request@lists.torproject.org

You can reach the person managing the list at
 tor-dev-owner@lists.torproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."

Today's Topics:

   1. Re: Auto-senescence and/or CW penalty for a less outdated tor
      network? (nusenu)

Message: 1
Date: Mon, 18 Sep 2017 17:30:00 +0000
From: nusenu <nusenu-lists@riseup.net>
To: tor-dev@lists.torproject.org
Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less
 outdated tor network?
Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981@riseup.net>
Content-Type: text/plain; charset="windows-1252"

 1) Auto-senescence
 -------------------

 I think automatic timed shutdown can be unhelpful or dangerous:

Yes it reduces the number of options once such a feature would be
implemented and deployed.

 * what if we need it earlier due to a severe bug or mandatory feature?

This should not be an issue since that auto-shutdown only mandates an
upper limit but does not stop you from removing a relay before that
limit has been reached.

 * what if it isn't needed, and the relay version is fine?

Yes this can be an issue, but if you say "every relay that runs versions
past its eol date" [1] is "not fine" then the auto-shutdown date can be
specified with a very high likelihood to a date that is past the eol
date because you have an estimate of how long you plan to support it (3y
for LTS).

I'm less concerned about auto-shutdown for tor clients since most tor
users might be using TBB with auto updates and it would help you having
to do things like prop266.

[1]
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

 2) consensus weight penalty for outdated relays

 I can't see much point in this: if the relays are insecure, they
 should be eliminated. If not, they should be used.

I'm happy with "insecure -> should be removed".
With "outdated" I meant "not running a recommended version" I'm not sure
if that is the same as 'insecure'.

A CW penalty would be a strong incentive for relay operators to keep
their relays up to date (to a recommended version).
This would likely reduce the number of relays running not-recommended
versions because currently the incentive is inverted (never
restart/update your tor instance - uptime!).
..but it would also affect testers running master.

 3) update tor dir auth code to reject old tor releases (not include them
 in consensus)

 In the past, we've excluded relay versions when they don't have a
 required feature. 

Does this step (excluding specific versions) require a code change or a
dir auth configuration change? (like it does for changing recommended
versions list)
If it does: Maybe it could be turned into a configurable option for dir
auths like recommended version.

(3) will not stop old relays from contacting dir auths.

 We have a ticket to make a plan to kill off old client versions:
 https://trac.torproject.org/projects/tor/ticket/15940
 But there's no equivalent ticket for relay versions.