diff options
| -rw-r--r-- | dir-spec.txt | 7 | ||||
| -rw-r--r-- | proposals/222-remove-client-timestamps.txt | 25 | ||||
| -rw-r--r-- | rend-spec.txt | 9 | ||||
| -rw-r--r-- | tor-spec.txt | 6 |
4 files changed, 35 insertions, 12 deletions
diff --git a/dir-spec.txt b/dir-spec.txt index 7222a3b..538170e 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1417,6 +1417,13 @@ entry for a router that isn't based on at least three measurements. + "Support022HiddenServices" -- Used to implement a mass switch-over + from sending timestamps to hidden services by default to sending + no timestamps at all. If this option is absent, or is set to 1, + clients with the default configuration send timestamps; otherwise, + they do not. + Min: 0, Max: 1. Default: 1. + The authority section of a vote contains the following items, followed in turn by the authority's current key certificate: diff --git a/proposals/222-remove-client-timestamps.txt b/proposals/222-remove-client-timestamps.txt index dd84bf2..7cd9cc5 100644 --- a/proposals/222-remove-client-timestamps.txt +++ b/proposals/222-remove-client-timestamps.txt @@ -3,7 +3,8 @@ Title: Stop sending client timestamps Authors: Nick Mathewson Created: 22 August 2013 Target: 0.2.5.x -Status: Open +Status: Closed +Implemented-In: 0.2.4.?? 0. Summary @@ -46,12 +47,14 @@ Status: Open The AUTHENTICATE cell is not ordinarily sent by clients. It contains an 8-byte timestamp and a 16-byte random value. - Instead, let's replace both with a 24-byte (truncated) HMAC of - the current time, using a random key. + Instead, let's just send 24 bytes or random value. - This will achieve the goal of including a timestamp in the - cell (preventing replays even in the presence of bad entropy), - while at the same time not including the time here. + (An earlier version of this proposal suggested that we replace + them both with a 24-byte (truncated) HMAC of the current time, + using a random key, in an attempt to retain the allegedly + desirable property of avoiding nonce duplication in the event of + a bad RNG. But really, a Tor process with a bad RNG is not going + to get security in any case, so let's KISS.) 2.3. TLS @@ -89,7 +92,7 @@ Status: Open Hidden service descriptors include a publication time. I propose that we round this time down to the nearest N minutes, - perhaps for N=30. + where N=60. 4.2. INTRODUCE2 cell timestamp @@ -102,8 +105,12 @@ Status: Open 0.2.2.x (and really, no hidden services should be running on 0.2.2.x!), we can simply send 0 instead. (See ticket #7803). - This might be a good place to use a consensus parameter, so - that a large number of clients switch at the same time. + We can control this behavior with a consensus parameter + (Support022HiddenServices) and a tristate (0/1/auto) torrc option of + the same name. + + When the timestamp is not completely disabled, it should be + rounded to the closest 10 minutes. I claim this would be suitable for backport to 0.2.4. diff --git a/rend-spec.txt b/rend-spec.txt index ca40fb5..ebaf4e8 100644 --- a/rend-spec.txt +++ b/rend-spec.txt @@ -301,7 +301,8 @@ [Exactly once] - A timestamp when this descriptor has been created. + A timestamp when this descriptor has been created. It should be + rounded down to the nearest hour. "protocol-versions" SP version-string NL @@ -668,6 +669,12 @@ v1, and v2 since 0.1.1.x. As of Tor 0.2.0.7-alpha and 0.1.2.18, clients switched to using the v2 intro format. + The Timestampe (TS) field is no longer used in Tor 0.2.3.9-alpha and + later. Clients MAY refrain from sending it; see the + "Support022HiddenServices" parameter in dir-spec.txt. Clients SHOULD + NOT send a precise timestamp, and should instead round to the nearest + 10 minutes. + 1.9. Introduction: From the Introduction Point to Bob's OP If the Introduction Point recognizes PK_ID as a public key which has diff --git a/tor-spec.txt b/tor-spec.txt index 8471bff..5561201 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -627,8 +627,10 @@ see tor-design.pdf. - the NUL terminated ASCII string: "Tor V3 handshake TLS cross-certification" [32 octets] - TIME: The time of day in seconds since the POSIX epoch. [8 octets] - RAND: A 16 byte value, randomly chosen by the initiator [16 octets] + RAND: A 24 byte value, randomly chosen by the initiator. (In an + imitation of SSL3's gmt_unix_time field, older versions of Tor + sent an 8-byte timestamp as the first 8 bytes of this field; + new implementations should not do that.) [24 octets] SIG: A signature of a SHA256 hash of all the previous fields using the initiator's "Authenticate" key as presented. (As always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt |