Filename: 297-safer-protover-shutdowns.txt Title: Relaxing the protover-based shutdown rules Author: Nick Mathewson Created: 19-Sep-2018 Status: Open Target: 0.3.5.x
1. Introduction
In proposal 264 (now implemented) we introduced the subprotocol versioning mechanism to better handle forward-compatibility in the Tor network. Included was a mechanism for safely disabling obsolete versions of Tor that no longer ran any supported protocols. If a version of Tor receives a consensus that lists as "required" any protocol version that it cannot speak, Tor will not start--even if the consensus is in its cache.
The intended use case for this is that once some protocol has been provided by all supported versions for a long time, the authorities can mark it as "required". We had thought about the "adding a requirement" case mostly.
This past weekend, though, we found an unwanted side-effect: it is hard to safely *un*-require a currently required protocol.
Here's what happened:
- Long ago, we created the LinkAuth=1 protocol, which required direct access to the ClientRandom and ServerRandom fields. (0.2.3.6-alpha)
- Later, once we implemented Ed25519 identity keys, we added an improved LinkAuth=3 protocol, which uses the RFC5705 "key export" mechanism. (0.3.0.1-alpha)
- When we added the subprotocols mechanism, we listed LinkAuth=1 as required. (backported to 0.2.9.x)
- While porting Tor to NSS, we found that LinkAuth=1 couldn't be supported, because NSS wisely declines to expose the TLS fields it uses. So we removed "LinkAuth=1" from the required list (backported to 0.3.2.x), and got a bunch of authorities to upgrade.
- In 0.3.5.1-alpha, once enough authorities had upgraded, we removed "LinkAuth=1" from the supported subprotocols list when Tor is running with NSS. [*]
- We found, however, that this change could cause a bug when Tor+NSS started with a cached consensus that was created before LinkAuth=1 was removed from the requirements. Tor would decline to start, because the (old) consensus told it that LinkAuth=1 was required.
This proposal discusses two alternatives for making it safe to remove required subprotocol versions in the future.
[*] There was actually a bug here where OpenSSL removed LinkAuth=1 too, but that's mostly beside the point for this timeline, other than the fact it would have made things waaay worse if people hadn't caught it.
2. Recommended change: consider the consensus date.
I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date.
With this change, an old cached consensus cannot cause the implementation to shut down, but a newer one can. This makes it safe to put out a release that does not support a formerly required protocol, so long as the authorities have upgraded to stop requiring that protocol.
(It is safe to use the *scheduled* release date for the implementation, plus a few months -- just so long as we don't plan to start requiring a subprotocol that's not supported by the latest version of Tor.)
3. Not-recommended change: ignore the cached consensus.
Was it a mistake to have Tor consider a cached consensus when deciding whether to shut down?
The rationale for considering the cached consensus was that when a Tor implementation is obsolete, we don't want it hammering on the network, probing for new consensuses, and possibly reconnecting aggressively as its handshakes fail. That still seems compelling to me, though it's possible that if we find some problem with the methodology from section 2 above, we'll need to find some other way to achieve this goal.
Hi,
This proposal seems good to me.
On 20 Sep 2018, at 02:20, Nick Mathewson nickm@torproject.org wrote:
I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date.
How does an implementation discover its' release date? Are we going to hard-code a date in the code? If so, how are we going to remember to update that date?
T
On Thu, Sep 20, 2018 at 09:40:49AM +1000, teor wrote:
Hi,
This proposal seems good to me.
On 20 Sep 2018, at 02:20, Nick Mathewson nickm@torproject.org wrote:
I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date.
How does an implementation discover its' release date? Are we going to hard-code a date in the code? If so, how are we going to remember to update that date?
If you make it use, say, the timestamp on the tip git commit of the source, then it's (a) automated, and (b) reproducible. But that's more of a build date than a release date, of course. (That's what otr uses.)
- Ian
Hi,
On 20/09/18 00:51, Ian Goldberg wrote:
If you make it use, say, the timestamp on the tip git commit of the source, then it's (a) automated, and (b) reproducible. But that's more of a build date than a release date, of course. (That's what otr uses.)
Please don't make your build system depend on git!
Distributions don't want to ship the entire project history with every package release.
stem had been doing this and as a result the test suite had never been run as part of the build process for the Debian package, which always starts from a tarball with no VCS information. (This is now fixed in stem).
https://trac.torproject.org/projects/tor/ticket/26984
Thanks, Iain.
On Thu, Sep 20, 2018 at 02:47:23PM +0100, Iain Learmonth wrote:
Hi,
On 20/09/18 00:51, Ian Goldberg wrote:
If you make it use, say, the timestamp on the tip git commit of the source, then it's (a) automated, and (b) reproducible. But that's more of a build date than a release date, of course. (That's what otr uses.)
Please don't make your build system depend on git!
Distributions don't want to ship the entire project history with every package release.
stem had been doing this and as a result the test suite had never been run as part of the build process for the Debian package, which always starts from a tarball with no VCS information. (This is now fixed in stem).
To be clear, the place this is used in otr is exactly to build the released *source tarball* from git, so that even the source tarball is reproducible. The binary package builders then build (reproducible) binaries from the reproducible source tarball.
- Ian
Hi,
On 20/09/18 17:03, Ian Goldberg wrote:
To be clear, the place this is used in otr is exactly to build the released *source tarball* from git, so that even the source tarball is reproducible. The binary package builders then build (reproducible) binaries from the reproducible source tarball.
I guess this is less bad. Still it is nice to have a backup mechanism in place to allow for things to work when git isn't around.
I notice that tor's changelogs do have dates. Can we reliably parse that out and set it to midnight or midday or whatever for time if git information isn't around (which would likely be the case when you're looking at a release not in between releases where the date might still be ??)?
Thanks, Iain.
On Wed, Sep 19, 2018 at 7:41 PM teor teor@riseup.net wrote:
Hi,
This proposal seems good to me.
On 20 Sep 2018, at 02:20, Nick Mathewson nickm@torproject.org wrote:
I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date.
How does an implementation discover its' release date? Are we going to hard-code a date in the code? If so, how are we going to remember to update that date?
I suggest that when we start a new release series, we set the release date to three months after the planned stable date for that series.
-
Iain Learmonth -
Ian Goldberg -
Nick Mathewson -
Nick Mathewson -
teor