From 3b8a1436c962157ac31e926fc16d5ff7e01ccd52 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 14 Mar 2022 12:27:36 -0400 Subject: Proposal 338: Use an 8-byte timestamp in NETINFO cells --- proposals/338-netinfo-y2038.md | 79 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 proposals/338-netinfo-y2038.md (limited to 'proposals/338-netinfo-y2038.md') diff --git a/proposals/338-netinfo-y2038.md b/proposals/338-netinfo-y2038.md new file mode 100644 index 0000000..a1a0385 --- /dev/null +++ b/proposals/338-netinfo-y2038.md @@ -0,0 +1,79 @@ +``` +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. -- cgit v1.2.3-54-g00ecf