Y2106 problem in NETINFO cell

The NETINFO cell includes a 4 byte timestamp counted in seconds; we should fix that to be an 8 byte timestamp before it is too late.

The easy way to do this would be to add a new link handshake version, and change the NETINFO cell in that version to have an 8 byte timestamp. (But if we do this, Arti won't benefit from it until it also implements the connection padding required in link protocol 5 and later: arti#62 (closed))

The harder kludgier way to do that would be to optionally insert the high bytes of the timestamp cell at the end of the end of the NETINFO cell, after the MYADDR stuff.

A bad kludge (IMO) would to specify that parties should interpret the timestamp as having whatever high bytes would make it closest to their current time.

Implementation breakdown, if prop338 is accepted

• In tor:
  • Add version 6 to accepted versions list
  • Add support for netinfo cell with 8 byte time.
  • Change format of netinfo cell depending on protocol version
  • Unit tests for all of the above
  • Integration testing with old/new clients, old/new relays
• In arti:
  • Add version 6 to accepted versions list (dup)
  • Add support for netinfo cell with 8 byte time. (dup)
  • Change format of netinfo cell depending on protocol version (dup)
  • Unit tests for all of the above (dup)
  • Integration testing with old/new clients, old/new relays (dup)
  • Add support for parsing channel cells differently depending on link protocol version

added Technical Debt label

assigned to @nickm

This is now proposal 338.

Initial public release: https://lists.torproject.org/pipermail/tor-dev/2022-March/014703.html

changed the description

added Doing label

added Backlog label and removed Doing label

added Q2 label

IIUC we decided that this is not urgent, and that since we have 15 years to solve this, we can safely let it become an arti-only fix once arti gets relay support.

removed Q2 label

added Icebox label and removed Backlog label

FWIW, assuming that we have implemented everything right, this is not a Y2038 problem but rather a Y2106 problem (since the 32-bit field is unsigned).

changed title from Y2038 problem in NETINFO cell to Y2106 problem in NETINFO cell