[tor-commits] [torspec/main] Proposal 338: Use an 8-byte timestamp in NETINFO cells
nickm at torproject.org
nickm at torproject.org
Mon Mar 14 16:43:40 UTC 2022
commit 3b8a1436c962157ac31e926fc16d5ff7e01ccd52
Author: Nick Mathewson <nickm at torproject.org>
Date: Mon Mar 14 12:27:36 2022 -0400
Proposal 338: Use an 8-byte timestamp in NETINFO cells
---
proposals/000-index.txt | 2 ++
proposals/338-netinfo-y2038.md | 79 ++++++++++++++++++++++++++++++++++++++++++
proposals/BY_INDEX.md | 1 +
proposals/README.md | 1 +
4 files changed, 83 insertions(+)
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
More information about the tor-commits
mailing list