[tor-commits] [torspec/master] prop224: Clarify behavior when uploading/fetching descriptors.

[asn at torproject.org]

commit d21a06c00de5ddb461414f3c845d429a0f4b9712
Author: George Kadianakis <desnacked at riseup.net>
Date:   Thu Apr 21 14:15:21 2016 +0300

    prop224: Clarify behavior when uploading/fetching descriptors.
    
    Specifically concering time periods and SRVs.
---
 proposals/224-rend-spec-ng.txt | 68 ++++++++++++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 16 deletions(-)

diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 3bc1d97..bad3a47 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -666,21 +666,6 @@ Status: Draft
    system, new shared random values get published at 00:00UTC every day,
    whereas the overlap period starts at 06:00 and finishes at 12:00UTC.
 
-   Here is an illustration of the system:
-
-      +------------------------------------------------------------------+
-      |                                                                  |
-      | 00:00      12:00       00:00       12:00       00:00       12:00 |
-      | SRV#1      TP#1        SRV#2       TP#2        SRV#3       TP#3  |
-      |                                                                  |
-      |   $         |-----------$-----======|-----------$-----======|    |
-      |                            overlap12               overlap23     |
-      |                                                                  |
-      +------------------------------------------------------------------+
-
-                                      Legend:    [TP#1 = Time Period #1]
-                                                 [SRV#1 = Shared Random Value #1]
-
 2.2.3. Where to publish a service descriptor
 
    The following consensus parameters control where a hidden service
@@ -757,7 +742,55 @@ Status: Draft
    least 3 hours after the descriptor expiration, so that clients with skewed
    clocks can still visit them through outdated descriptors.
 
-2.2.4. URLs for anonymous uploading and downloading
+2.2.4. Using time periods and SRVs to fetch/upload HS descriptors
+
+   Hidden services and clients need to make correct use of time periods and
+   shared random values (SRVs) to successfuly fetch and upload descriptors.
+
+   As [PUB-SHAREDRANDOM] specifies, consensuses contain two shared random
+   values (the current one and the previous one). Hidden services and clients
+   are asked to match these shared random values with descriptor time periods
+   and use the right SRV when fetching/uploading descriptors. This section
+   attempts to precisely specify how this works.
+
+   Let's start with an illustration of the system:
+
+      +------------------------------------------------------------------+
+      |                                                                  |
+      | 00:00      12:00       00:00       12:00       00:00       12:00 |
+      | SRV#1      TP#1        SRV#2       TP#2        SRV#3       TP#3  |
+      |                                                                  |
+      |   $         |-----------$-----======|-----------$-----======|    |
+      |                            overlap12               overlap23     |
+      |                                                                  |
+      +------------------------------------------------------------------+
+
+                                      Legend:    [TP#1 = Time Period #1]
+                                                 [SRV#1 = Shared Random Value #1]
+
+   First of all, during overlap periods, hidden services always use the
+   _current_ SRV for publishing overlap descriptors. Clients MUST ignore the
+   overlap period and instead always fetch the current descriptor as described
+   below.
+
+   The rest of the time, hidden services and clients need to choose the right SRV
+   to use based on the current time period to upload/fetch the current descriptor.
+
+   Looking at the diagram above, SRV#1 gets published 12 hours before TP#1
+   starts and TP#1 lasts 24 hours. By defining the lifetime of SRV#1 to be 36
+   hours, we can pair SRV#1 with TP#1.
+
+   Hence, when clients and hidden services first see an SRV for the first time,
+   they calculate its expiry date (using a 36 hour lifetime) and use that SRV
+   for uploading/fetching descriptors till it expires. When that SRV expires,
+   they switch to the next SRV in the consensus.
+
+   During overlap periods, hidden services upload both normal descriptors and
+   overlap descriptors as described above.
+
+   For more examples and discussion on this technique, please see [SRV-TP-REFS].
+
+2.2.5. URLs for anonymous uploading and downloading
 
    Hidden service descriptors conforming to this specification are
    uploaded with an HTTP POST request to the URL
@@ -1607,6 +1640,9 @@ References:
         http://projectbullrun.org/dual-ec/ext-rand.html
         https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html
 
+[SRV-TP-REFS]:
+        https://lists.torproject.org/pipermail/tor-dev/2016-April/010759.html
+
 Appendix A. Signature scheme with key blinding [KEYBLIND]
 
   As described in [IMD:DIST] and [SUBCRED] above, we require a "key