Proposal 338: Use an 8-byte timestamp in NETINFO cells

4 files changed, 83 insertions, 0 deletions

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 40152dd..c078e13 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -258,6 +258,7 @@ Proposals by number:
 335  An authority-only design for MiddleOnly [CLOSED]
 336  Randomized schedule for guard retries [OPEN]
 337  A simpler way to decide, "Is this guard usable?" [OPEN]
+338  Use an 8-byte timestamp in NETINFO cells [OPEN]
 
 
 Proposals by status:
@@ -300,6 +301,7 @@ Proposals by status:
    330  Modernizing authority contact entries
    336  Randomized schedule for guard retries
    337  A simpler way to decide, "Is this guard usable?"
+   338  Use an 8-byte timestamp in NETINFO cells
  ACCEPTED:
    265  Load Balancing with Overhead Parameters [for 0.2.9.x]
    275  Stop including meaningful "published" time in microdescriptor consensus [for 0.3.1.x-alpha]
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.
diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md
index e6bf782..484ad13 100644
--- a/proposals/BY_INDEX.md
+++ b/proposals/BY_INDEX.md
@@ -255,4 +255,5 @@ Below are a list of proposals sorted by their proposal number.  See
 * [`335-middle-only-redux.md`](/proposals/335-middle-only-redux.md): An authority-only design for MiddleOnly [CLOSED]
 * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [OPEN]
 * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [OPEN]
+* [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells [OPEN]
 
diff --git a/proposals/README.md b/proposals/README.md
index 512ea26..8152d8b 100644
--- a/proposals/README.md
+++ b/proposals/README.md
@@ -42,6 +42,7 @@ for discussion.
 * [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries
 * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries
 * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?"
+* [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells
 
 
 ## ACCEPTED proposals: slated for implementation