[or-cvs] [tor/master] Update rend-spec.txt.

Nick Mathewson nickm at seul.org
Mon May 4 17:50:31 UTC 2009


Author: Karsten Loesing <karsten.loesing at gmx.net>
Date: Sun, 3 May 2009 00:34:36 +0200
Subject: Update rend-spec.txt.
Commit: 592f9571690514ebff0df9732b927bbfdba136a7

---
 ChangeLog              |    4 ++
 doc/spec/rend-spec.txt |  110 ++++++++++++++++++++---------------------------
 2 files changed, 51 insertions(+), 63 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2365670..4ca2b1e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -7,6 +7,10 @@ Changes in version 0.2.2.1-alpha - 2009-??-??
   o Deprecated and removed features:
     - The controller no longer accepts the old obsolete "addr-mappings/"
       GETINFO value.
+    - Hidden services no longer publish version 0 descriptors, and clients
+      do not request or use version 0 descriptors. However, the authorities
+      still accept and serve version 0 descriptors when contacted by older
+      hidden services/clients.
 
 
 Changes in version 0.2.1.15??? - ????-??-??
diff --git a/doc/spec/rend-spec.txt b/doc/spec/rend-spec.txt
index e3fbe22..5c2f698 100644
--- a/doc/spec/rend-spec.txt
+++ b/doc/spec/rend-spec.txt
@@ -145,33 +145,10 @@ $Id$
 1.2. Bob's OP generates service descriptors.
 
    The first time the OP provides an advertised service, it generates
-   a public/private keypair (stored locally).  Periodically, the OP
-   generates and publishes a descriptor of type "V0".
+   a public/private keypair (stored locally).
 
-   The "V0" descriptor contains:
-
-         KL    Key length                            [2 octets]
-         PK    Bob's public key                      [KL octets]
-         TS    A timestamp                           [4 octets]
-         NI    Number of introduction points         [2 octets]
-         Ipt   A list of NUL-terminated ORs          [variable]
-         SIG   Signature of above fields             [variable]
-
-   KL is the length of PK, in octets.
-   TS is the number of seconds elapsed since Jan 1, 1970.
-
-   The members of Ipt may be either (a) nicknames, or (b) identity key
-   digests, encoded in hex, and prefixed with a '$'.  Clients must
-   accept both forms. Services must only generate the second form.
-   Once 0.0.9.x is obsoleted, we can drop the first form.
-
-   [It's ok for Bob to advertise 0 introduction points. He might want
-    to do that if he previously advertised some introduction points,
-    and now he doesn't have any. -RD]
-
-   Beginning with 0.2.0.10-alpha, Bob's OP encodes "V2" descriptors in
-   addition to "V0" descriptors. The format of a "V2" descriptor is as
-   follows:
+   Beginning with 0.2.0.10-alpha, Bob's OP encodes "V2" descriptors. The
+   format of a "V2" descriptor is as follows:
 
      "rendezvous-service-descriptor" descriptor-id NL
 
@@ -340,6 +317,10 @@ $Id$
 
         (This ends the fields in the encrypted portion of the descriptor.)
 
+       [It's ok for Bob to advertise 0 introduction points. He might want
+        to do that if he previously advertised some introduction points,
+        and now he doesn't have any. -RD]
+
      "signature" NL signature-string
 
        [At end, exactly once]
@@ -349,6 +330,21 @@ $Id$
 
 1.2.1. Other descriptor formats we don't use.
 
+   Support for the V0 descriptor format was dropped in 0.2.2.0-alpha-dev:
+
+         KL    Key length                            [2 octets]
+         PK    Bob's public key                      [KL octets]
+         TS    A timestamp                           [4 octets]
+         NI    Number of introduction points         [2 octets]
+         Ipt   A list of NUL-terminated ORs          [variable]
+         SIG   Signature of above fields             [variable]
+
+   KL is the length of PK, in octets.
+   TS is the number of seconds elapsed since Jan 1, 1970.
+
+   The members of Ipt may be either (a) nicknames, or (b) identity key
+   digests, encoded in hex, and prefixed with a '$'.
+
    The V1 descriptor format was understood and accepted from
    0.1.1.5-alpha-cvs to 0.2.0.6-alpha-dev, but no Tors generated it and
    it was removed:
@@ -409,7 +405,7 @@ $Id$
    RELAY_ESTABLISH_INTRO cell, containing:
 
         KL   Key length                             [2 octets]
-        PK   Bob's public key                       [KL octets]
+        PK   Introduction public key                [KL octets]
         HS   Hash of session info                   [20 octets]
         SIG  Signature of above information         [variable]
 
@@ -431,16 +427,13 @@ $Id$
    currently associated with PK.  On success, the OR sends Bob a
    RELAY_INTRO_ESTABLISHED cell with an empty payload.
 
-   If a hidden service is configured to publish only v2 hidden service
-   descriptors, Bob's OP does not include its own public key in the
-   RELAY_ESTABLISH_INTRO cell, but the public key of a freshly generated
-   key pair. The OP also includes these fresh public keys in the v2 hidden
-   service descriptor together with the other introduction point
-   information. The reason is that the introduction point does not need to
-   and therefore should not know for which hidden service it works, so as
-   to prevent it from tracking the hidden service's activity. If the hidden
-   service is configured to publish both, v0 and v2 descriptors, two
-   separate sets of introduction points are established.
+   Bob's OP does not include its own public key in the RELAY_ESTABLISH_INTRO
+   cell, but the public key of a freshly generated introduction key pair.
+   The OP also includes these fresh public keys in the v2 hidden service
+   descriptor together with the other introduction point information. The
+   reason is that the introduction point does not need to and therefore
+   should not know for which hidden service it works, so as to prevent it
+   from tracking the hidden service's activity.
 
 1.4. Bob's OP advertises his service descriptor(s).
 
@@ -464,10 +457,8 @@ $Id$
    after its timestamp.  At least every 18 hours, Bob's OP uploads a
    fresh descriptor.
 
-   If Bob's OP is configured to publish v2 descriptors instead of or in
-   addition to v0 descriptors, it does so to a changing subset of all v2
-   hidden service directories instead of the authoritative directory
-   servers. Therefore, Bob's OP opens a stream via Tor to each
+   Bob's OP publishes v2 descriptors to a changing subset of all v2 hidden
+   service directories. Therefore, Bob's OP opens a stream via Tor to each
    responsible hidden service directory. (He may re-use old circuits
    for this.) Over this stream, Bob's OP makes an HTTP 'POST' request to a
    URL "/tor/rendezvous2/publish" relative to the hidden service
@@ -520,12 +511,21 @@ $Id$
 
 1.6. Alice's OP retrieves a service descriptor.
 
-   Alice opens a stream to a directory server via Tor, and makes an HTTP GET
-   request for the document '/tor/rendezvous/<z>', where '<z>' is replaced
-   with the encoding of Bob's public key as described above. (She may re-use
-   old circuits for this.) The directory replies with a 404 HTTP response if
-   it does not recognize <z>, and otherwise returns Bob's most recently
-   uploaded service descriptor.
+   Similarly to the description in section 1.4, Alice's OP fetches a v2
+   descriptor from a randomly chosen hidden service directory out of the
+   changing subset of 6 nodes. If the request is unsuccessful, Alice retries
+   the other remaining responsible hidden service directories in a random
+   order. Alice relies on Bob to care about a potential clock skew between
+   the two by possibly storing two sets of descriptors (see end of section
+   1.4).
+
+   Alice's OP opens a stream via Tor to the chosen v2 hidden service
+   directory. (She may re-use old circuits for this.) Over this stream,
+   Alice's OP makes an HTTP 'GET' request for the document
+   "/tor/rendezvous2/<z>", where z is replaced with the encoding of the
+   descriptor ID. The directory replies with a 404 HTTP response if it does
+   not recognize <z>, and otherwise returns Bob's most recently uploaded
+   service descriptor.
 
    If Alice's OP receives a 404 response, it tries the other directory
    servers, and only fails the lookup if none recognize the public key hash.
@@ -541,22 +541,6 @@ $Id$
    [Caching may make her partitionable, but she fetched it anonymously,
     and we can't very well *not* cache it. -RD]
 
-   Alice's OP fetches v2 descriptors in parallel to v0 descriptors. Similarly
-   to the description in section 1.4, the OP fetches a v2 descriptor from a
-   randomly chosen hidden service directory out of the changing subset of
-   6 nodes. If the request is unsuccessful, Alice retries the other
-   remaining responsible hidden service directories in a random order.
-   Alice relies on Bob to care about a potential clock skew between the two
-   by possibly storing two sets of descriptors (see end of section 1.4).
-
-   Alice's OP opens a stream via Tor to the chosen v2 hidden service
-   directory. (She may re-use old circuits for this.) Over this stream,
-   Alice's OP makes an HTTP 'GET' request for the document
-   "/tor/rendezvous2/<z>", where z is replaced with the encoding of the
-   descriptor ID. The directory replies with a 404 HTTP response if it does
-   not recognize <z>, and otherwise returns Bob's most recently uploaded
-   service descriptor.
-
 1.7. Alice's OP establishes a rendezvous point.
 
    When Alice requests a connection to a given location-hidden service,
-- 
1.5.6.5




More information about the tor-commits mailing list