sarah
/
tor
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update rend-spec.txt.

This commit is contained in:
Karsten Loesing 2009-05-03 00:34:36 +02:00 committed by Nick Mathewson
parent f79688ddef
commit 592f957169
2 changed files with 51 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
ChangeLog
View File

@ -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??? - ????-??-??

110
doc/spec/rend-spec.txt
View File

@ -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,