Re: [tor-dev] Proposal 318: Limit protover values to 0-63

[teor <teor@xxxxxxxxxx>]

Hi Nick,

> On 12 May 2020, at 06:47, Nick Mathewson <nickm@xxxxxxxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev