Proposal 338: Use an 8-byte handshake in NETINFO cells
``` Filename: 338-netinfo-y2038.md Title: Use an 8-byte timestamp in NETINFO cells Author: Nick Mathewson Created: 2022-03-14 Status: Open ``` # Introduction Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp will overflow on 19 January 2038. Let's get ahead of the problem and squash this issue now, by expanding the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough to outlast the Earth's sun.) # Proposed change I propose adding a new link protocol version. (The next one in sequence, as of this writing, is version 6.) I propose that we change the text of tor-spec section 4.5 from: ``` TIME (Timestamp) [4 bytes] ``` to ``` TIME (Timestamp) [4 or 8 bytes *] ``` and specify that this field is 4 bytes wide on link protocols 1-5, but 8 bytes wide on link protocols 6 and beyond. # Rejected alternatives Our protocol specifies that parties MUST ignore extra data at the end of cells. Therefore we _could_ add additional data at the end of the NETINFO cell, and use that to store the high 4 bytes of the timestamp without having to increase the link protocol version number. I propose that we don't do that: it's ugly. As another alternative, we could declare that parties must interpret the timestamp such that its high 4 bytes place it as close as possible to their current time. I'm rejecting this kludge because it would give confusing results in the too-common case where clients have their clocks mis-set to Jan 1, 1970. # Impacts on our implementations Arti won't be able to implement this change until it supports connection padding (as required by link protocol 5), which is currently planned for the next Arti milestone (1.0.0, scheduled for this fall). If we think that that's a problem, or if we want to have support for implementations without connection padding in the future, we should reconsider this plan so that connection padding support is independent from 8-byte timestamps. # Other timestamps in Tor I've done a cursory search of our protocols to see if we have any other instances of the Y2038 problem. There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned integer counting _hours_ since the Unix epoch, which will keep it from wrapping around till 478756 C.E. (The rollover date of "10136 CE" reported in `cert-spec` is wrong, and seems to be based on the misapprehension that the counter is in *minutes*.) The v2 onion service protocol has 4-byte timestamps, but it is thoroughly deprecated and unsupported. I couldn't find any other 4-byte timestamps, but that is no guarantee: others should look for them too.
On 3/14/22 11:44, Nick Mathewson wrote: <snip>
Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp will overflow on 19 January 2038.
Let's get ahead of the problem and squash this issue now, by expanding the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough to outlast the Earth's sun.)
<snip> With all those extra bits, would there be any value to using a more granular time measure? e.g. microseconds? If not, would it be worth saving some bytes and only expanding to 5 bytes? (I know; it *feels* wrong, but I can't think of much real downside)
On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome <jnewsome@torproject.org> wrote:
On 3/14/22 11:44, Nick Mathewson wrote:
<snip>
Currently Tor relays use a 4-byte timestamp (in seconds since the Unix epoch) in their NETINFO cells. Notoriously, such a timestamp will overflow on 19 January 2038.
Let's get ahead of the problem and squash this issue now, by expanding the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough to outlast the Earth's sun.)
<snip>
With all those extra bits, would there be any value to using a more granular time measure? e.g. microseconds?
I don't think so, necessarily. We aren't doing full NTP here; in fact, we're just trying to detect clock skew that's big enough to break Tor. (Like, on the order of hours.) I don't think we'll get anything useful out of sub-second observations. If not, would it be worth saving some bytes and only expanding to 5
bytes? (I know; it *feels* wrong, but I can't think of much real downside)
Hm, possibly. One downside is that 5-byte decoder/encoder functions aren't exactly common, so we'd require everybody to build one. (Or to do something like u8 ts_high; u32 ts_low; ) Since the extra 3 bytes are only used once per connection attempt, I'm pretty comfortable letting them be useless until 36812 CE or whenever.
On 3/14/22 14:40, Nick Mathewson wrote:
On Mon, Mar 14, 2022 at 3:18 PM Jim Newsome <jnewsome@torproject.org <mailto:jnewsome@torproject.org>> wrote:
On 3/14/22 11:44, Nick Mathewson wrote:
<snip>
> Currently Tor relays use a 4-byte timestamp (in seconds since the Unix > epoch) in their NETINFO cells. Notoriously, such a timestamp will > overflow on 19 January 2038. > > Let's get ahead of the problem and squash this issue now, by expanding > the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough > to outlast the Earth's sun.)
<snip>
With all those extra bits, would there be any value to using a more granular time measure? e.g. microseconds?
I don't think so, necessarily. We aren't doing full NTP here; in fact, we're just trying to detect clock skew that's big enough to break Tor. (Like, on the order of hours.) I don't think we'll get anything useful out of sub-second observations.
If not, would it be worth saving some bytes and only expanding to 5 bytes? (I know; it *feels* wrong, but I can't think of much real downside)
Hm, possibly. One downside is that 5-byte decoder/encoder functions aren't exactly common, so we'd require everybody to build one. (Or to do something like u8 ts_high; u32 ts_low; )
Since the extra 3 bytes are only used once per connection attempt, I'm pretty comfortable letting them be useless until 36812 CE or whenever.
Makes sense to me. Thanks!
participants (2)
-
Jim Newsome -
Nick Mathewson