diff options
Diffstat (limited to 'proposals/224-rend-spec-ng.txt')
| -rw-r--r-- | proposals/224-rend-spec-ng.txt | 104 |
1 files changed, 43 insertions, 61 deletions
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 1c4762f..93cc0c6 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -1,6 +1,6 @@ Filename: 224-rend-spec-ng.txt Title: Next-Generation Hidden Services in Tor -Author: Nick Mathewson +Author: David Goulet, George Kadianakis, Nick Mathewson Created: 2013-11-29 Status: Accepted @@ -54,8 +54,7 @@ Table of contents: 3.1.3. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] 3.2.1. INTRODUCE1 cell format [FMT_INTRO1] - 3.2.2. Legacy formats [LEGACY-INTRODUCE1] - 3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] + 3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] 3.3. Processing an INTRODUCE2 cell at the hidden service. [PROCESS_INTRO2] 3.3.1. Introduction handshake encryption requirements [INTRO-HANDSHAKE-REQS] 3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA] @@ -102,11 +101,6 @@ Table of contents: the responder does not, hidden services attempt to provide bidirectional anonymity. - Other features include: - - * [TODO: WRITE ME once there have been some more drafts and we know - what the summary should say.] - Participants: Operator -- A person running a hidden service @@ -129,12 +123,18 @@ Table of contents: Rendezvous Point -- A Tor node to which clients and servers connect and which relays traffic between them. - - 0.1. Improvements over previous versions. - [TODO write me once there have been more drafts and we know what the - summary should say.] + Here is a list of improvements of this proposal over the legacy hidden + services: + + a) Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519) + b) Improved directory protocol leaking less to directory servers. + c) Improved directory protocol with smaller surface for targeted attacks. + d) Better onion address security against impersonation. + e) More extensible introduction/rendezvous protocol. + f) Offline keys for onion services + g) Advanced client authorization 0.2. Notation and vocabulary @@ -308,8 +308,6 @@ Table of contents: 0.6. Acknowledgments - [TODO reformat these once the lists are more complete.] - This design includes ideas from many people, including Christopher Baines, Daniel J. Bernstein, @@ -319,6 +317,11 @@ Table of contents: Aniket Kate, Tanja Lange, Robert Ransom, + Roger Dingledine, + Aaron Johnson, + Tim Wilson-Brown ("teor"), + special (John Brooks), + s7r It's based on Tor's original hidden service design by Roger Dingledine, Nick Mathewson, and Paul Syverson, and on improvements to @@ -635,12 +638,9 @@ Table of contents: 2. Generating and publishing hidden service descriptors [HSDIR] Hidden service descriptors follow the same metaformat as other Tor - directory objects. They are published anonymously to Tor servers with - the HSDir3 flag. - - (Authorities should assign this flag as they currently assign the - HSDir flag, except that they should restrict it to Tor versions - implementing the HSDir parts of this specification.) + directory objects. They are published anonymously to Tor servers with the + HSDir flag, HSDir=2 protocol version and tor version >= 0.3.0.8 (because a + bug was fixed in this version). 2.1. Deriving blinded keys and subcredentials [SUBCRED] @@ -1348,8 +1348,7 @@ Table of contents: [None or at most once per introduction point] The key is an ASN.1 encoded RSA public key in PEM format used for a - legacy introduction point as described in [LEGACY_EST_INTRO] and - [LEGACY-INTRODUCE1] below. + legacy introduction point as described in [LEGACY_EST_INTRO]. This field is only present if the introduction point only supports legacy protocol (v2) that is <= 0.2.9 or the protocol version value @@ -1586,14 +1585,14 @@ Table of contents: EXT_FIELD [EXT_FIELD_LEN bytes] ENCRYPTED [Up to end of relay payload] + AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of + AUTH_KEY_TYPE for this cell is an Ed25519 public key [02]. + The LEGACY_KEY_ID field is used to distinguish between legacy and new style INTRODUCE1 cells. In new style INTRODUCE1 cells, LEGACY_KEY_ID is 20 zero bytes. Upon receiving an INTRODUCE1 cell, the introduction point checks the LEGACY_KEY_ID field. If LEGACY_KEY_ID is non-zero, the INTRODUCE1 cell - should be handled as specified in [LEGACY-INTRODUCE1]. - - AUTH_KEY_TYPE is defined as in [EST_INTRO]. Currently, the only value of - AUTH_KEY_TYPE for this cell is an Ed25519 public key [02]. + should be handled as a legacy INTRODUCE1 cell by the intro point. Upon receiving a INTRODUCE1 cell, the introduction point checks whether AUTH_KEY matches the introduction point authentication key for an @@ -1601,27 +1600,7 @@ Table of contents: INTRODUCE2 cell with exactly the same contents to the service, and sends an INTRODUCE_ACK response to the client. -3.2.2. Legacy formats [LEGACY-INTRODUCE1] - - For legacy introduction points, INTRODUCE1 cells should be of the form: - - LEGACY_KEY_ID [20 bytes] - N_EXTENSIONS [1 byte] - N_EXTENSIONS times: - EXT_FIELD_TYPE [1 byte] - EXT_FIELD_LEN [1 byte] - EXT_FIELD [EXT_FIELD_LEN bytes] - ENCRYPTED [Up to end of relay payload] - - Here, LEGACY_KEY_ID is the hash of the introduction point legacy - encryption key that was included in the hidden service descriptor. - - Because of limitations in older versions of Tor, the relay payload size for - these INTRODUCE1 cells must always be at least 246 bytes, or they will be - rejected as invalid. The ENCRYPTED field may contain padding to reach this - length. - -3.2.3. INTRODUCE_ACK cell format. [INTRO_ACK] +3.2.2. INTRODUCE_ACK cell format. [INTRO_ACK] An INTRODUCE_ACK cell has the following fields: @@ -1644,11 +1623,11 @@ Table of contents: the AUTH_KEY or LEGACY_KEY_ID field matches the keys for this introduction circuit. - The service host then checks whether it has received a cell with - these contents before. If it has, it silently drops it as a - replay. (It must maintain a replay cache for as long as it accepts - cells with the same encryption key. Note that the encryption format below - should be non-malleable.) + The service host then checks whether it has received a cell with these + contents or rendezvous cookie before. If it has, it silently drops it as a + replay. (It must maintain a replay cache for as long as it accepts cells + with the same encryption key. Note that the encryption format below should + be non-malleable.) If the cell is not a replay, it decrypts the ENCRYPTED field, establishes a shared key with the client, and authenticates the whole @@ -1788,10 +1767,7 @@ Table of contents: (This format is as documented in [FMT_INTRO1] above, except that here - we describe how to build the ENCRYPTED portion. If the introduction - point is running an older Tor that does not support this protocol, - the first field is replaced by a 20-byte AUTH_KEYID_HASH field as - described in [LEGACY-INTRODUCE1].) + we describe how to build the ENCRYPTED portion.) Here, the encryption key plays the role of B in the regular ntor handshake, and the AUTH_KEY field plays the role of the node ID. @@ -1930,7 +1906,7 @@ Table of contents: If the cookie matches the rendezvous cookie set on any not-yet-connected circuit on the rendezvous point, the rendezvous point connects the two circuits, and sends a RENDEZVOUS2 cell to the - client containing the contents of the RENDEZVOUS1 cell. + client containing the HANDSHAKE_INFO field of the RENDEZVOUS1 cell. Upon receiving the RENDEZVOUS2 cell, the client verifies that HANDSHAKE_INFO correctly completes a handshake. To do so, the client parses SERVER_PK from @@ -2082,6 +2058,9 @@ References: J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. http://cr.yp.to/papers.html#ed25519 +[ED25519-B-REF]: + https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-5: + [PRNG-REFS]: http://projectbullrun.org/dual-ec/ext-rand.html https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html @@ -2135,10 +2114,13 @@ A.2. Tor's key derivation scheme addition. See the Ed25519 paper [Reference ED25519-REFS] for a fairly clear writeup.) - Let the basepoint be written as B. Assume B has prime order l, so - lB=0. Let a master keypair be written as (a,A), where a is the private - key and A is the public key (A=aB) -. + Let B be the ed25519 basepoint as found in section 5 of [ED25519-B-REF]: + B = (15112221349535400772501151409588531511454012693041857206046113283949847762202, + 46316835694926478169428394003475163141307993866256225615783033603165251855960) + + Assume B has prime order l, so lB=0. Let a master keypair be written as + (a,A), where a is the private key and A is the public key (A=aB). + To derive the key for a nonce N and an optional secret s, compute the blinding factor like this: |