[tor-commits] [torspec/master] Add proposal 318, to limit the range of subprotocol versions.

[nickm at torproject.org]

commit 4625a59da9b6b27bbc803c271d1b7c94497917e1
Author: Nick Mathewson <nickm at torproject.org>
Date:   Mon May 11 16:02:59 2020 -0400

    Add proposal 318, to limit the range of subprotocol versions.
---
 proposals/000-index.txt          |  2 ++
 proposals/318-limit-protovers.md | 45 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 98dbf6b..ecfa49b 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -238,6 +238,7 @@ Proposals by number:
 315  Updating the list of fields required in directory documents [OPEN]
 316  FlashFlow: A Secure Speed Test for Tor (Parent Proposal) [DRAFT]
 317  Improve security aspects of DNS name resolution [OPEN]
+318  Limit protover values to 0-63 [OPEN]
 
 
 Proposals by status:
@@ -281,6 +282,7 @@ Proposals by status:
    310  Towards load-balancing in Prop 271
    315  Updating the list of fields required in directory documents
    317  Improve security aspects of DNS name resolution
+   318  Limit protover values to 0-63
  ACCEPTED:
    188  Bridge Guards and other anti-enumeration defenses
    249  Allow CREATE cells with >505 bytes of handshake data
diff --git a/proposals/318-limit-protovers.md b/proposals/318-limit-protovers.md
new file mode 100644
index 0000000..08f3a16
--- /dev/null
+++ b/proposals/318-limit-protovers.md
@@ -0,0 +1,45 @@
+```
+Filename: 318-limit-protovers.md
+Title: Limit protover values to 0-63.
+Author: Nick Mathewson
+Created: 11 May 2020
+Status: Open
+```
+
+# Limit protover values to 0-63.
+
+I propose that we no longer accept protover values higher than 63,
+so that they can all fit nicely into 64-bit fields.
+
+(This proposal is part of the Walking Onions spec project.)
+
+## Motivation
+
+Doing this will simplify our implementations and our protocols.
+Right now, an efficient protover implementation needs to use ranges
+to represent possible protocol versions, and needs workarounds to
+prevent an attacker from constructing a protover line that would
+consume too much memory.  With Walking Onions, we need lists of
+protocol versions to be represented in an extremely compact format,
+which also would benefit from a limited set of possible versions.
+
+I believe that we will lose nothing by making this
+change. Currently, after nearly two decades of Tor development
+and 3.5 years of experiences with protovers in production, we have
+no protocol version high than 5.
+
+Even if we did someday need to implement higher protocol
+versions, we could simply add a new subprotocol name instead.  For
+example, instead of "HSIntro=64", we could say "HSIntro2=1".
+
+## Migration
+
+Immediately, authorities should begin rejecting relays with protocol
+versions above 63.  (There are no such relays in the consensus right
+now.)
+
+Once this change is deployed to a majority of authorities, we can
+remove support in other Tor environments for protocol versions
+above 63.
+
+