``` 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.
Hi Nick,
On 12 May 2020, at 06:47, Nick Mathewson nickm@torproject.org wrote:
``` 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.
If you'd like to make the format even more compact, you could also lower these limits:
const MAX_PROTOCOLS_TO_EXPAND: usize = 1 << 16; const MAX_PROTOCOL_NAME_LENGTH: usize = 100;
In particular: * now that protocols can only have 63 versions, we can directly limit the maximum number of protocol names. (Rather than indirectly limiting them via the expansion limit.) We currently have 12 protocol names, so a suitable limit might be 50. * depending on the parsing algorithm, we might not need an expansion limit any more. If we do, we should set the limit to (max versions)*(max names) or lower. * our current protocol names are all 4-9 characters, so we could lower the name limit to 30.
That way, the maximum length of a compact list would be: 8 bytes per protocol version * 50 protocols = 400 bytes of versions 30 bytes per protocol name * 50 protocols = 1500 bytes of names
Hmm, maybe that's a bit high, and we should drop some of those limits even further.
…
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".
If we drop the name limit, it should be high enough to support new protocols, and extensions to existing protocols.
## 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.
As you said in your previous email, bridge clients can start rejecting descriptors along with regular clients. Even though they get their descriptors directly from bridges.
T