Add proposal 318, to limit the range of subprotocol versions.

2 files changed, 47 insertions, 0 deletions

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.
+
+