commit 4625a59da9b6b27bbc803c271d1b7c94497917e1 Author: Nick Mathewson nickm@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. + +