diff options
author | Nick Mathewson <nickm@torproject.org> | 2018-09-19 12:19:44 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2018-09-19 12:19:44 -0400 |
commit | bd6733234b70972baa6866fce86e601d7063c5b8 (patch) | |
tree | feee039998dcf3d523936d5725ba518ee8d8ebcd /proposals/297-safer-protover-shutdowns.txt | |
parent | 46573d278068dc519d5a7d7473628a824ee6701a (diff) | |
download | torspec-bd6733234b70972baa6866fce86e601d7063c5b8.tar.gz torspec-bd6733234b70972baa6866fce86e601d7063c5b8.zip |
Add proposal for making protover shutdown logic safer
Diffstat (limited to 'proposals/297-safer-protover-shutdowns.txt')
-rw-r--r-- | proposals/297-safer-protover-shutdowns.txt | 98 |
1 files changed, 98 insertions, 0 deletions
diff --git a/proposals/297-safer-protover-shutdowns.txt b/proposals/297-safer-protover-shutdowns.txt new file mode 100644 index 0000000..0307df3 --- /dev/null +++ b/proposals/297-safer-protover-shutdowns.txt @@ -0,0 +1,98 @@ +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. + + + + + |