<div dir="ltr">```<br>Filename: 338-netinfo-y2038.md<br>Title: Use an 8-byte timestamp in NETINFO cells<br>Author: Nick Mathewson<br>Created: 2022-03-14<br>Status: Open<br>```<br><br># Introduction<br><br>Currently Tor relays use a 4-byte timestamp (in seconds since the Unix<br>epoch) in their NETINFO cells.  Notoriously, such a timestamp will<br>overflow on 19 January 2038.<br><br>Let's get ahead of the problem and squash this issue now, by expanding<br>the timestamp to 8 bytes. (8 bytes worth of seconds will be long enough<br>to outlast the Earth's sun.)<br><br># Proposed change<br><br>I propose adding a new link protocol version.  (The next one in<br>sequence, as of this writing, is version 6.)<br><br>I propose that we change the text of tor-spec section 4.5 from:<br><br>```<br>      TIME       (Timestamp)                     [4 bytes]<br>```<br><br>to<br><br>```<br>     TIME       (Timestamp)                     [4 or 8 bytes *]<br>```<br><br>and specify that this field is 4 bytes wide on link protocols 1-5, but 8<br>bytes wide on link protocols 6 and beyond.<br><br># Rejected alternatives<br><br>Our protocol specifies that parties MUST ignore extra data at the end of<br>cells. Therefore we _could_ add additional data at the end of the<br>NETINFO cell, and use that to store the high 4 bytes of the timestamp<br>without having to increase the link protocol version number.  I propose<br>that we don't do that: it's ugly.<br><br>As another alternative, we could declare that parties must interpret the<br>timestamp such that its high 4 bytes place it as close as possible to<br>their current time.  I'm rejecting this kludge because it would give<br>confusing results in the too-common case where clients have their clocks<br>mis-set to Jan 1, 1970.<br><br># Impacts on our implementations<br><br>Arti won't be able to implement this change until it supports connection<br>padding (as required by link protocol 5), which is currently planned for<br>the next Arti milestone (1.0.0, scheduled for this fall).<br><br>If we think that that's a problem, or if we want to have support for<br>implementations without connection padding in the future, we should<br>reconsider this plan so that connection padding support is independent<br>from 8-byte timestamps.<br><br># Other timestamps in Tor<br><br>I've done a cursory search of our protocols to see if we have any other<br>instances of the Y2038 problem.<br><br>There is a 4-byte timestamp in `cert-spec`, but that one is an unsigned<br>integer counting _hours_ since the Unix epoch, which will keep it from<br>wrapping around till 478756 C.E. (The rollover date of "10136 CE"<br>reported in `cert-spec` is wrong, and seems to be based on the<br>misapprehension that the counter is in *minutes*.)<br><br>The v2 onion service protocol has 4-byte timestamps, but it is<br>thoroughly deprecated and unsupported.<br><br>I couldn't find any other 4-byte timestamps, but that is no guarantee:<br>others should look for them too.<br></div>