[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Add proposal 318, to limit the range of subprotocol versions.
commit 4625a59da9b6b27bbc803c271d1b7c94497917e1
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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.
+
+
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits