- tor-dev - lists.torproject.org

Draft of proposal "Stop HS address enumeration by HSDirs"
by George Kadianakis 18 Aug '13

18 Aug '13

Greetz, I'm posting the draft of a proposal that specifies how to hide HS descriptors and addresses from the hidden service directories. This proposal is supposed to go along with the proposal that specifies how to upgrade HS identity keys to use Ed25519. I posted that proposal some seconds ago. This proposal (like the other one) is incredibly drafty in the sense that I might have forgotten to specify things that need to be specified. On the other hand, "release early; release often" they say, so here it goes. Inlining: Filename: xxx-onion-antienumeration-hsdirs.txt Title: Stop HS address enumeration by HSDirs Author: George Kadianakis Created: 16 August 2013 Target: 0.2.5.x Status: Draft [More draft than Guiness.] 0. Proposal overview and motivation: Currently, it is the case that, HSDirs can read the descriptors of the Hidden Services they host. Even if the descriptor was encrypted, HSDirs could still learn the address of the HSes by logging the client directory requests (which contain the hidden service address). This proposal: a) Defines cryptographic procedures to be followed by Tor clients and hidden services to allow HS address antienumeration. b) Defines a new descriptor format which hides the descriptor content from entities who don't know the public key of the HS. c) Changes the size (and semantics) of Hidden Service addresses. 1. Acknowledgments The cryptography behind this proposal was originally proposed by Robert Ransom in a private email threadi and subsequently posted in tor-dev [0]. Discussion was continued in trac ticket #8106 [1]. During the past 6 months many bright people have looked at the cryptography behind this scheme. The list of people includes Nadia Heninger, Leonid Reyzin, Nick Hopper, Aggelos Kiayias, Tanja Lange, Dan J. Bernstein and probably others that I can't recall at this point. Thanks! 2. Parameters TIME_PERIOD is XXX 3. Scheme overview Currently, Hidden Services upload their unencrypted descriptor to hidden service directories (HSDirs). HSDirs store the unencrypted descriptor in an internal map of: <hs address> -> <hs descriptor> When a client wants the descriptor of an HS, it asks an HSDir for the descriptor that corresponds to <hs address>. If the HSDir has such an index in its map, it returns the <hs descriptor> to the client. This proposal asks Hidden Services, to periodically derive a new ephemeral keypair from its long-term identity key; the new keypair is a function of the identity key and a time-dependent nonce. The derivation should be one-way; if you know the identity key you should be able to derive the ephemeral key, but not the other way around. Finally, a client should be able to derive the ephemeral HS public key from the long-term HS public key without knowing the long-term HS private key (#KEYPAIRDERIVATION) Hidden Services then encrypt their descriptor with a symmetric key (derived from the ephemeral public key) and sign the ciphertext and the ephemeral public key with their ephemeral private key. Then they place the ephemeral public key, the encrypted descriptor and the signature in a "metadescriptor" document (#METADESC) and send it to the HSDir (#DESCPUBLISH). The HSDir validates the signature of the "metadescriptor", and if it's legit it stores the metadescriptor in an internal map of: <ephemeral public key> -> <metadescriptor> . (#DESCPUBLISH) Now, out of band, the HS gives to its clients a <z>.onion address. <z> in this case is the long-term public key of the HS (this is different from the current situation where <z> is the hash of the long-term public key). A client that knows the <z>.onion address and wants to acquire the HS descriptor, derives the <ephemeral public key> of the HS by using <z> and the same key derivation procedure that the HS uses. She also derives the symmetric key that decrypts the encrypted HS descriptor (#DESCFETCH). The client then contacts the appropriate HSDir and inquires for the descriptor with index <ephemeral public key>. If the HSDir has such an index in its internal map, it passes the <metadescriptor> to the client (#DESCFETCH). The client then verifies the signature of the metadescriptor, and if it's legit she decrypts the encrypted descriptor with the symmetric key. The client now has the Hidden Servide descriptor she was so looking for (#DESCDECRYPTION). 4. Security proof XXX A security proof of the above scheme is under development. We are not going to implement or deploy anything before we have a solid proof of this. 5. Changes to the current HS protocol 5.0. Related proposals This proposal is supposed to be applied on top of the "Migrate HS identity keys to Ed25519" proposal. 5.1. Ephemeral keypair derivation (#KEYPAIRDERIVATION) XXX Leaving this unpsecified for now till the security proof comes along. For now, let's assume that after this paragraph each HS has a per-TIME_PERIOD ephemeral keypair. It also has a symmetric key derived from the ephemeral public key (maybe even the hash of the ephemeral public key) to encrypt its descriptor. Let's also assume that each client can generate the ephemeral public key of a HS given only its long-term public key (and knowledge of the current time-dependent nonce). 5.2. HS descriptor publishing 5.2.1. Metadescriptor format (#METADESC) The format of the metadescriptor that is uploaded to the HSDir is: "ephemeral-public-key" NL public-key [At start, exactly once] The ephemeral public key for this time period in base64 encoding. "encrypted-descriptor" NL encrypted-descriptor [Exactly once] An encrypted v3 hidden service descriptor (as specified in xxx-hs-ecc-id-keys.txt). It's encrypted using the ephemeral symmetric key of the HS, encoded in base64 and surrounded with "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----". "signature" NL signature [At end, exactly once] A signature of all fields above with the ephemeral private key of the hidden service. 5.2.2. Metadescriptor publishing (#DESCPUBLISH) The metadescriptor specified above is published to the appropriate HSDir by sending an HTTP 'POST' request to "/tor/rendezvous3/publish" as specified in the "Migrate HS identity keys to Ed25519" proposal. # XXX should this get its own URI, even though we assume that these two proposals will be implemented and deployed simultaneously? Upon receiving a descriptor, the directory server checks the signature, and discards the descriptor if the signature does not match the enclosed public key. If the signature matches, the directory server saves the descriptor in a map of: <ephemeral-public-key> -> <metadescriptor>. 5.3. Metadescriptor fetching (#DESCFETCH) A client that knows the long-term public key (onion address) of a hidden service can derive the ephemeral public key and the ephemeral symmetric key as specified in section 5.1. A client that wants to fetch the metadescriptor of an HS, does an HTTP 'GET' request to the appropriate directory server asking for "/tor/rendezvous3/<z>" where <z> is the ephemeral public key of the HS. # XXX should this get its own URI, even though we assume that these two proposals will be implemented and deployed simultaneously? 5.4. Metadescriptor decryption (#DESCDECRYPTION) The client then verifies the signature of the metadescriptor, and discards it if it doesn't match the ephemeral public key that was previously derived. If the signature matches, the client uses the derived ephemeral symmetric key to decrypt the 'encrypted-descriptor' part of the metadescriptor. 6. Discussion [Points here might deserve their own sections] Do we need the HSDir hash ring, even though the HS address and the descriptor are now hidden from HSDirs? An ed25519 public key is 32 bytes. 32 bytes in base32 encoding is 56 characters (or 52 with the '=' padding removed). Do we want a different URL encoding or are we happy with addresses like: mfrggzdfmztwq2lknnwg23tpobyxe43uov3ho6dzpjaueq2eivda.onion ? Refs: [0]: https://lists.torproject.org/pipermail/tor-dev/2012-September/004026.html . [1]: https://trac.torproject.org/projects/tor/ticket/8106

5 7

Globe without search term
by Karsten Loesing 15 Aug '13

15 Aug '13

21:43 #tor-dev: < rndm> karsten, looks like this now if it gets the maximum number of results http://globe.rndm.de/#/search/query= You're not online now, so replying via email: Looks really good! Minor tweaks to the phrasing: "To avoid too many requests," -> the better motivation is that a) we don't want to overload the poor Onionoo server and b) reduce delays and bandwidth requirements for the client. I think users will understand b) better and not care much about a). How about "To reduce waiting time and limit bandwidth usage," ? "try to use a search word" -> this message also shows up if the user tried a search term that is too general. How about "try to refine your search" ? Thanks! Nice work! Best, Karsten

2 5

[draft] Proposal 220: Migrate server identity keys to Ed25519
by Nick Mathewson 14 Aug '13

14 Aug '13

Here's a proposal I wrote about node key migration. I hope it meshes well with the authority identity migration proposal that Jake and Linus are doing. There are probably holes and mistakes here: let's fix them. Filename: 220-ecc-id-keys.txt Title: Migrate server identity keys to Ed25519 Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.5.x Status: Draft [Note: This is a draft proposal; I've probably made some important mistakes, and there are parts that need more thinking. I'm publishing it now so that we can do the thinking together.] 0. Introduction In current Tor designs, identity keys are limited to 1024-bit RSA keys. Clearly, that should change, because RSA doesn't represent a good performance-security tradeoff nowadays, and because 1024-bit RSA is just plain too short. We've already got an improved circuit extension handshake protocol that uses curve25519 in place of RSA1024, and we're using (where supported) P256 ECDHE in our TLS handshakes, but there are more uses of RSA1024 to replace, including: * Router identity keys * TLS link keys * Hidden service keys This proposal describes how we'll migrate away from using 1024-bit RSA in the first two, since they're tightly coupled. Hidden service crypto changes will be complex, and will merit their own proposal. In this proposal, we'll also (incidentally) be extirpating a number of SHA1 usages. 1. Overview When this proposal is implemented, every router will have an Ed25519 identity key in addition to its current RSA1024 public key. Ed25519 (specifically, Ed25519-SHA-512 as described and specified at http://ed25519.cr.yp.to/) is a desirable choice here: it's secure, fast, has small keys and small signatures, is bulletproof in several important ways, and supports fast batch verification. (It isn't quite as fast as RSA1024 when it comes to public key operations, since RSA gets to take advantage of small exponents when generating public keys.) (For reference: In Ed25519 public keys are 32 bytes long, private keys are 64 bytes long, and signatures are 64 bytes long.) To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. 1.1. 'Personalized' signatures Each of the keys introduced here is used to sign more than one kind of document. While these documents should be unambiguous, I'd going to forward-proof the signatures by specifying each signature to be generated, not on the document itself, but on the document prefixed with some distinguishing string. 2. Certificates and Router descriptors. 2.1. Certificates When generating a signing key, we also generate a certificate for it. Unlike the certificates for authorities' signing keys, these certificates need to be sent around frequently, in significant numbers. So we'll choose a compact representation. VERSION [1 Byte] TYPE [1 Byte] CERTIFIED_KEY [32 Bytes] EXPIRATION_DATE [4 Bytes] EXTRA_STUFF [variable length] SIGNATURE [64 Bytes] The "VERSION" field holds the value [01]. The "TYPE" field holds the value [01]. The CERTIFIED_KEY field is an Ed25519 public key. The expiration date is a day, given in DAYS since the epoch, after which this certificate isn't valid. The EXTRA_STUFF field is left for a future version of this format. [XXXX Is "EXTRA_STUFF" a good idea? -NM] Before processing any certificate, parties MUST know which identity key it is supposed to be signed by, and then check the signature. The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string "Tor node signing key certificate v1". We also specify a revocation document for revoking a signing key or an identity key. Its format is: FIXED_PREFIX [8 Bytes] VERSION [1 Byte] KEYTYPE [1 Byte] IDENTITY_KEY [32 Bytes] REVOKED_KEY [32 Bytes] PUBLISHED [8 Bytes] EXTRA_STUFF [variable length] SIGNATURE [64 Bytes] FIXED_PREFIX is "REVOKEID" or "REVOKESK". VERSION is [01]. KEYTYPE is [01] for revoking a signing key or [02] or revoking an identity key. REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's Ed25519 identity key. PUBLISHED is the time that the document was generated, in seconds since the epoch. EXTRA_STUFF is left for a future version of this document. The SIGNATURE is generated with the same key as in IDENTITY_KEY, and covers the entire revocation, prefixed with "Tor key revocation v1". Using these revocation documents is unspecified. 2.2. Managing keys By default, we can keep the easy-to-setup key management properties that Tor has now, so that node operators aren't required to have offline public keys: * When a Tor node starts up with no Ed25519 identity keys, it generates a new identity keypair. * When a Tor node has an Ed25519 identity keypair, and it has no signing key, or its signing key is going to expire within the next 48 hours, it generates a new signing key to last 30 days. But we also support offline identity keys: * When a Tor node starts with an Ed25519 public identity key but no private identity key, it checks wither it has a currently valid certified signing keypair. If it does, it starts. Otherwise, it refuses to start. * If a Tor node's signing key is going to expire soon, it starts warning the user. If it is expired, then the node shuts down. 2.3. Router descriptors We specify the following element that may appear at most once in each router descriptor: "identity-ed25519" SP identity-key SP certification NL The identity-key and certification are base64 encoded with terminating =s removed. When this element is present, it MUST appear as the first or second element in the router descriptor. [XXX The rationale here is to allow extracting the identity key and signing key and checking the signature before fully parsing the rest of the document. -NM] When an identity-ed25519 element is present, there must also be an "router-signature-ed25519" element. It MUST be the next-to-last element in the descriptor, appearing immediately before RSA signature. It MUST contain an ed25519 signature of the entire document, from the first character up to but not including the "router-signature-ed25519" element, prefixed with the string "Tor router descriptor signature v1". Its format is: "router-signature-ed25519" SP signature NL Were 'signature' is encoded in base64 with terminating =s removed. The identity key in the identity-ed25519 key MUST be the one used to sign the certification, and the signing key in the certification MUST be the one used to sign the document. Note that these keys cross-certify as follows: the ed25519 identity key signs the ed25519 signing key in the certificate. The ed25519 signing key signs itself and the ed25519 identity key and the RSA identity key as part of signing the descriptor. And the RSA identity key also signs all three keys as part of signing the descriptor. 2.3.1. Checking descriptor signatures. Current versions of Tor will handle these new formats by ignoring the new fields, and not checking any ed25519 information. New version of Tor will have a flag that tells them whether to check ed25519 information. When it is set, they must check: * All RSA information and signatures that Tor implementations currently check. * If the identity-ed25519 line is present, it must be well-formed, and the certificate must be well-formed and correctly signed, and there must be a valid. * If we require an ed25519 key for this node (see 3.1 below), the ed25519 key must be present. Authorities and directory caches will have this flag always-on. For clients, it will be controlled by a torrc option and consensus option, to be set to "always-on" in the future once enough clients support it. 2.3.2. Extra-info documents Extrainfo documents now include "identity-ed25519" and "router-signature-ed25519" fields in the same positions in which they appear in router descriptors. Additionally, we add the base64-encoded, =-stripped SHA256 digest of a node's extra-info document field to the extra-info-digest line. (All versions of Tor that recognize this line allow an extra field there.) 2.3.3. A note on signature verification Here and elsewhere, we're receiving a certificate and a document signed with the key certified by that certificate in the same step. This is a fine time to use the batch signature checking capability of Ed25519, so that we can check both signatures at once without (much) additional overhead over checking a single signature. 3. Consensus documents and authority operation 3.1. Handling router identity at the authority When receiving router descriptors, authorities must track mappings between RSA and Ed25519 keys. Rule 1: Once an authority has seen an Ed25519 identity key and an RSA identity key together on the same (valid) descriptor, it should no longer accept any descriptor signed by that RSA key with a different Ed25519 key, or that Ed25519 key with a different RSA key. Rule 2: Once an authority has seen an Ed25519 identity key and an RSA identity key on the same descriptor, it should no longer accept any descriptor signed by that RSA key unless it also has that Ed25519 key. These rules together should enforce the property that, even if an attacker manages to steal or factor a node's RSA identity key, the attacker can't impersonate that node to the authorities, even when that node is identified by its RSA key. Enforcement of Rule 1 should be advisory-only for a little while (a release or two) while node operators get experience having Ed25519 keys, in case there are any bugs that cause or force identity key replacement. Enforcement of Rule 2 should be advisory-only for little while, so that node operators can try 0.2.5 but downgrade to 0.2.4 without being de-listed from the consensus. [XXX I could specify a way to do a signed "I'm downgrading for a while!" statement, and kludge some code back into 0.2.4.x to better support that?] 3.2. Formats Vote and consensus documents now contain an optional "id" field for each routerstatus section. Its format is: "id" SP ed25519-identity NL where ed25519-identity is base-64 encoded, with trailing = characters omitted. In vote documents, it may be replaced by the format: "id" SP "none" NL which indicates that the node does not have an ed25519 identity. (In the consensus, a lack of "id" line means that the node has no ed25519 identity.) [XXXX Should the id entries in consensuses go into microdescriptors instead? I think perhaps so. -NM] A vote or consensus document is ill-formed if it includes the same ed25519 identity key twice. 3.3. Generating votes An authority should pick which descriptor to choose for a node as before, and include the ed25519 identity key for the descriptor if it's present. As a transition, before Rule 1 and Rule 2 in 3.1 are fully enforced, authorities need a way to deal with the possibility that there might be two nodes with the same ed25519 key but different RSA keys. In that case, it votes for the one with the most recent publication date. (The existing rules already prevent an authority from voting for two servers with the same RSA identity key.) 3.4. Generating a consensus from votes This proposal requires a new consensus vote method. When we deploy it, we'll pick the next available vote method in sequence to use for this. When the new consensus method is in use, we must choose nodes first by ECC key, then by RSA key. First, for every {ECC identity key, RSA identity key} pair listed by over half of the voting authorities, list it, unless some other RSA identity key digest is listed more popularly for the ECC key. Break ties in favor of low RSA digests. Treat all routerstatus entries that mention this <ECC,RSA> pair as being for the same router, and all routerstatus entries that mention the same RSA key with an unspecified ECC key as being for the same router. Then, for every node that has previously not been listed, perform the current routerstatus algorithm: listing a node if it has been listed by at least N/2 voting authorities, and treating all routerstatuses containing the same identity as the same router. In other words: Let Entries = [] for each ECC ID listed by any voter: Find the RSA key associated with that ECC ID by the most voters, breaking ties in favor of low RSA keys. If that ECC ID and RSA key ID are listed by > N/2 voting authorities: Add the consensus of the routerstatus entries for those voters, along with the routerstatus entry for every voter that included that RSA key with no ECC key, to Entries. Include the ECC ID in the consensus. For each RSA key listed by any voter: If that RSA key is already in Entries, skip it. If the RSA key is listed by > N/2 voting authorities: Add the consensus of the routerstatus entries for those voters to Entries. Do not include an ECC key in the consensus. [XXX Think about this even more.] 4. The link protocol [XXX This section won't make much sense unless you grok the v3 connection protocol as described in tor-spec.txt, first proposed in proposal 195.] We add four new CertType values for use in CERTS cells: 4: Ed25519 signing key 5: Link key certificate certified by Ed25519 signing key 6: TLS authentication key certified by Ed25519 signing key 7: RSA cross-certification for Ed25519 identity key The content of certificate type 4 is: Ed25519 identity key [32 byets] Signing key certificate as in 2.1 above [variable length] The content of certificate type 5 is: CERT_DIGEST [32 bytes] EXPIRATION_DATE [4 bytes] EXTRA_STUFF [variable] SIGNATURE [64 bytes] where CERT_DIGEST is a SHA256 digest of the X.509 certificate used for the TLS link, EXPIRATION_DATE is a date in *days* since the epoch starting on which the certificate is invalid, and SIGNATURE is a signature using the signing key of the above two fields, prefixed with "Tor TLS link certificate check v1". The content of certificate type 6 is the same as the signing key in 2.1 above, except that the TYPE field is 02 and the fixed string used in signing is "". The Ed25519 key certified by this key can be used in AUTHENTICATE cells. The content of certificate type 7 is: ED25519_KEY [32 bytes] EXPIRATION_DATE [4 bytes] SIGNATURE [128 bytes] Here, the Ed25519 identity key is signed with router's identity key, to indicate that authenticating with a key certified by the Ed25519 key counts as certifying with RSA identity key. (The signature is computed on the SHA256 hash of the non-signature parts of the certificate, prefixed with the string "Tor TLS RSA/Ed25519 cross-certification".) (There's no reason to have a corresponding Ed25519-signed-RSA-key certificate here, since we do not treat authenticating with an RSA key as proving ownership of the Ed25519 identity.) Relays with Ed25519 keys should always send these certificate types in addition to their other certificate types. Non-bridge relays with Ed25519 keys should generate TLS link keys of appropriate strength, so that the certificate chain from the Ed25519 key to the link key is strong enough. We add a new authentication type for AUTHENTICATE cells: "Ed25519-TLSSecret", with AuthType value 2. Its format is the same as "RSA-SHA256-TLSSecret", except that the CID and SID fields support more key types; some strings are different, and the signature is performed with Ed25519 using the authentication key from a type-6 cert. TYPE: The characters "AUTH0002" [8 octets] CID: A SHA256 hash of the initiator's RSA1024 identity key [32 octets] SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets] CID_ED: The initiator's Ed25519 identity key [32 octets] SID_ED: The responder's Ed25519 identity key, or all-zero. [32 octets] SLOG: A SHA256 hash of all bytes sent from the responder to the initiator as part of the negotiation up to and including the AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell, the AUTH_CHALLENGE cell, and any padding cells. [32 octets] CLOG: A SHA256 hash of all bytes sent from the initiator to the responder as part of the negotiation so far; that is, the VERSIONS cell and the CERTS cell and any padding cells. [32 octets] SCERT: A SHA256 hash of the responder's TLS link certificate. [32 octets] TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the secret key, of the following: - client_random, as sent in the TLS Client Hello - server_random, as sent in the TLS Server Hello - the NUL terminated ASCII string: "Tor V3 handshake TLS cross-certification with Ed25519" [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] SIG: A signature of all previous fields using the initiator's Ed25519 authentication flags. [variable length] If you've got a consensus that lists an ECC key for a node, but the node doesn't give you an ECC key, then refuse this connection. 5. The extend protocol We add a new NSPEC node specifier for use in EXTEND2 cells, with LSTYPE value [03]. Its length must be 32 bytes; its content is the Ed25519 identity key of the target node. Clients should use this type only when: * They know an Ed25519 identity key for the destination node. * The source node supports EXTEND2 cells * A torrc option is set, _or_ a consensus value is set. We'll leave the consensus value off for a while until more clients support this, and then turn it on. When picking a channel for a circuit, if this NSPEC value is provided, then the RSA identity *and* the Ed25519 identity must match. If we have a channel with a given Ed25519 ID and RSA identity, and we have a request for that Ed25519 ID and a different RSA identity, we do not attempt to make another connection: we just fail and DESTROY the circuit. If we receive an EXTEND or EXTEND2 request for a node listed in the consensus, but that EXTEND/EXTEND2 request does not include an Ed25519 identity key, the node SHOULD treat the connection as failed if the Ed25519 identity key it receives does not match the one in the consensus. 6. Naming nodes in the interface Anywhere in the interface that takes an $identity should be able to take an ECC identity too. ECC identities are case-sensitive base64 encodings of Ed25519 identity keys. You can use $ to indicate them as well; we distinguish RSA identity digests length. When we need to indicate an Ed25519 identity key in an hostname format (as in a .exit address), we use the lowercased version of the name, and perform a case-insensitive match. (This loses us one bit per byte of name, Nodes must not list Ed25519 identities in their family lines; clients and authorities must not honor them there. Clients shouldn't accept .exit addresses with Ed25519 names on SOCKS or DNS ports by default, even when AllowDotExit is set. We need an identity-to-node map for ECC identity and for RSA identity. The controller interface will need to accept and report Ed25519 identity keys as well as (or instead of) RSA identity keys. That's a separate proposal, though. 7. Hidden service changes out of scope Hidden services need to be able identity nodes by ECC keys, just as they will need to include ntor keys as well as TAP keys. Not just yet though. This needs to be part of a bigger hidden service revamping strategy. 8. Proposed migration steps Once a few versions have shipped with Ed25519 key support, turn on "Rule 1" on the authorities. (Don't allow an Ed25519<->RSA pairing to change.) Once 0.2.5.x is in beta or rc, turn on the consensus option for everyone who receives descriptors with Ed25519 identity keys to check them. Once 0.2.5.x is in beta or rc, turn on the consensus option for clients to generate EXTEND2 requests with Ed25519 identity keys. Once 0.2.5.x has been stable for a month or two, turn on "Rule 2" on authorities. (Don't allow nodes that have advertised an Ed25519 key to stop.) 9. Future proposals * Ed25519 identity support on the controller interface * Supporting nodes without RSA keys * Remove support for nodes without Ed25519 keys * Ed25519 support for hidden services * Bridge identity support. * Ed25519-aware family support

5 8

[draft] Proposal 219: Support for full DNS and DNSSEC resolution in Tor
by Nick Mathewson 13 Aug '13

13 Aug '13

This is a proposal of Ondrej's from last year that I've edited a little, with permission. I'm assigning it a number so that we can keep it on the radar. Discussion invited! Let's try to answer the open questions too. Filename: 219-expanded-dns.txt Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 Modified: 2 August 2013 Target: 0.2.5.x Status: Draft 0. Overview Adding support for any DNS query type to Tor. 0.1. Motivation Many applications running over Tor need more than just resolving FQDN to IPv4 and vice versa. Sometimes to prevent DNS leaks the applications have to be hacked around to be supplied necessary data by hand (e.g. SRV records in XMPP). TLS connections will benefit from planned TLSA record that provides certificate pinning to avoid another Diginotar-like fiasco. 0.2. What about DNSSEC? Routine DNSSEC resolution is not practical with this proposal alone, because of round-trip issues: a single name lookup can require dozens of round trips across a circuit, rendering it very slow. (We don't want to add minutes to every webpage load time!) For records like TLSA that need extra signing, this might not be an unacceptable amount of overhead, but routine hostname lookup, it's probably overkill. [Further, thanks to the changes of proposal 205, DNSSEC for routine hostname lookup is less useful in Tor than it might have been back when we cached IPv4 and IPv6 addresses and used them across multiple circuits and exit nodes.] See section 8 below for more discussion of DNSSEC issues. 1. Design 1.1 New cells There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll use DNS_BEGIN and DNS_RESPONSE for short below). 1.1.1. DNS_BEGIN DNS_BEGIN payload: FLAGS [2 octets] DNS packet data (variable length, up to length of relay cell.) The DNS packet must be generated internally by Tor to avoid fingerprinting users by differences in client resolvers' behavior. [XXXX We need to specify the exact behavior here: saying "Just do what Libunbound does!" would make it impossible to implement a Tor-compatible client without reverse-engineering libunbound. - NM] The FLAGS field is reserved, and should be set to 0 by all clients. Because of the maximum length of the RELAY cell, the DNS packet may not be longer than 496 bytes. [XXXX Is this enough? -NM] Some fields in the query must be omitted or set to zero: see section 3 below. 1.1.2. DNS_RESPONSE DNS_RESPONSE payload: STATUS [1 octet] CONTENT [variable, up to length of relay cell] If the low bit of STATUS is set, this is the last DNS_RESPONSE that the server will send in response to the given DNS_BEGIN. Otherwise, there will be more DNS_RESPONSE packets. The other bits are reserved, and should be set to zero for now. The CONTENT fields of the DNS_RESPONSE cells contain a DNS record, split across multiple cells as needed, encoded as: total length (2 octets) data (variable) So for example, if the DNS record R1 is only 300 bytes long, then it is sent in a single DNS_RESPONSE cell with payload [01 01 2C] R1. But if the DNS record R2 is 1024 bytes long, it's sent in 3 DNS_RESPONSE cells, with contents: [00 04 00] R2[0:495], [00] R2[495:992], and [01] R2[992:1024] respectively. [NOTE: I'm using the length field and the is-this-the-last-cell field to allow multi-packet responses in the future. -NM] AXFR and IXRF are not supported in this cell by design (see specialized tool below in section 5). 1.1.3. Matching queries to responses. DNS_BEGIN must use a non-zero, distinct StreamID. The client MUST NOT re-use the same stream ID until it has received a complete response from the server or a RELAY_END cell. The client may cancel a DNS_BEGIN request by sending a RELAY_END cell. The server may refused to answer, or abort answering, a DNS_BEGIN cell by sending a RELAY_END cell. 2. Interfaces to applications DNSPort evdns - existing implementation will be updated to use DNS_BEGIN. [XXXX we should add a dig-like tool that can work over the socksport via some extension, as tor-resolve does now. -NM] 3. Limitations on DNS query Clients must only set query class to IN (INTERNET), since the only other useful class CHAOS is practical for directly querying authoritative servers (OR in this case acts as a recursive resolver). Servers MUST return REFUSED for any for class other than IN. Multiple questions in a single packet are not supported and OR will respond with REFUSED as the DNS error code. All query RR types are allowed. [XXXX I originally thought about some exit policy like "basic RR types" and "all RRs", but managing such list in deployed nodes with extra directory flags outweighs the benefit. Maybe disallow ANY RR type? -OM] Client as well as OR MUST block attempts to resolve local RFC 1918, 4193, or 4291 adresses (PTR). REFUSED will be returned as DNS error code from OR. [XXXX Must they also refuse to report addresses that resolve to these? -NM] [XXX I don't think so. People often use public DNS records that map to private adresses. We can't effectively separate "truly public" records from the ones client's dnsmasq or similar DNS resolver returns. - OM] [XXX Then do you mean "must be returned as the DNS error from the OP"?] Request for special names (.onion, .exit, .noconnect) must never be sent, and will return REFUSED. The DNS transaction ID field MUST be set to zero in all requests and replies; the stream ID field plays the same function in Tor. 4. Implementation notes Client will periodically purge incomplete DNS replies. Any unexpected DNS_RESPONSE will be dropped. AD flag must be zeroed out on client unless validation is performed. [XXXX libunbound lowlevel API, Tor+libunbound libevent loop libunbound doesn't publicly expose all the necessary parts of low-level API. It can return the received DNS packet, but not let you construct a packet and get it in wire-format, for example. Options I see: a) patch libunbound to be able feed wire-format DNS packets and add API to obtain constructed packets instead of sending over network b) replace bufferevents for sockets in unbound with something like libevent's paired bufferevents. This means that data extracted from DNS_RESPONSE/DNS_BEGIN cells would be fed directly to some evbuffers that would be picked up by libunbound. It could possibly result in avoiding background thread of libunbound's ub_resolve_async running separate libevent loop. c) bind to some arbitrary local address like 127.1.2.3:53 and use it as forwarder for libunbound. The code there would pack/unpack the DNS packets from/to libunbound into DNS_BEGIN/DNS_RESPONSE cells. It wouldn't require modification of libunbound code, but it's not pretty either. Also the bind port must be 53 which usually requires superuser privileges. Code of libunbound is fairly complex for me to see outright what would the best approach be. ] 5. Separate tool for AXFR The AXFR tool will have similar interface like tor-resolve, but will return raw DNS data. Parameters are: query domain, server IP of authoritative DNS. The tool will transfer the data through "ordinary" tunnel using RELAY_BEGIN and related cells. This design decision serves two goals: - DNS_BEGIN and DNS_RESPONSE will be simpler to implement (lower chance of bugs) - in practice it's often useful do AXFR queries on secondary authoritative DNS servers IXFR will not be supported (infrequent corner case, can be done by manual tunnel creation over Tor if truly necessary). 6. Security implications As proposal 171 mentions, we need mitigate circuit correlation. One solution would be keeping multiple streams to multiple exit nodes and picking one at random for DNS resolution. Other would be keeping DNS-resolving circuit open only for a short time (e.g. 1-2 minutes). Randomly changing the circuits however means that it would probably incur additional latency since there would likely be a few cache misses on the newly selected exits. [This needs more analysis; We need to consider the possible attacks here. It would be good to have a way to tie requests to SocksPorts, perhaps? -NM] 7. TTL normalization idea A bit complex on implementation, because it requires parsing DNS packets at exit node. TTL in reply DNS packet MUST be normalized at exit node so that client won't learn what other clients queried. The normalization is done in following way: - for a RR, the original TTL value received from authoritative DNS server should be used when sending DNS_RESPONSE, trimming the values to interval [5, 600] - does not pose "ghost-cache-attack", since once RR is flushed from libunbound's cache, it must be fetched anew 8. DNSSEC notes 8.1. Where to do the resolution? DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC API would be probably in OS libraries (e.g. libc). However that will probably take time until it becomes widespread. On the Tor's side (as opposed to application's side), DNSSEC will provide protection against DNS cache-poisoning attacks (provided that exit is not malicious itself, but still reduces attack surface). 8.2. Round trips and serialization Following are two examples of resolving two A records. The one for addons.mozila.org is an example of a "common" RR without CNAME/DNAME, the other for www.gov.cn an extreme example chained through 5 CNAMEs and 3 TLDs. The examples below are shown for resolving that started with an empty DNS cache. Note that multiple queries are made by libunbound as it tries to adjust for the latency of network. "Standard query response" below that does not list RR type is a negative NOERROR reply with NSEC/NSEC3 (usually reply to DS query). The effect of DNS cache plays a great role - once DS/DNSKEY for root and a TLD is cached, at most 3 records usually need to be fetched for a record that does not utilize CNAME/DNAME (3 roundtrips for DS, DNSKEY and the record itself if there are no zone cuts below). Query for addons.mozilla.org, 6 roundtrips (not counting retries): Standard query A addons.mozilla.org Standard query A addons.mozilla.org Standard query A addons.mozilla.org Standard query A addons.mozilla.org Standard query A addons.mozilla.org Standard query response A 63.245.217.112 RRSIG Standard query response A 63.245.217.112 RRSIG Standard query response A 63.245.217.112 RRSIG Standard query A addons.mozilla.org Standard query response A 63.245.217.112 RRSIG Standard query response A 63.245.217.112 RRSIG Standard query A addons.mozilla.org Standard query response A 63.245.217.112 RRSIG Standard query response A 63.245.217.112 RRSIG Standard query DNSKEY <Root> Standard query DNSKEY <Root> Standard query response DNSKEY DNSKEY RRSIG Standard query response DNSKEY DNSKEY RRSIG Standard query DS org Standard query response DS DS RRSIG Standard query DNSKEY org Standard query response DNSKEY DNSKEY DNSKEY DNSKEY RRSIG RRSIG Standard query DS mozilla.org Standard query response DS RRSIG Standard query DNSKEY mozilla.org Standard query response DNSKEY DNSKEY DNSKEY RRSIG RRSIG Query for www.gov.cn, 16 roundtrips (not counting retries): Standard query A www.gov.cn Standard query A www.gov.cn Standard query A www.gov.cn Standard query A www.gov.cn Standard query A www.gov.cn Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A www.gov.cn Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A www.gov.cn Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query response CNAME www.gov.chinacache.net CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A www.gov.chinacache.net Standard query response CNAME www.gov.cncssr.chinacache.net CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A www.gov.cncssr.chinacache.net Standard query response CNAME www.gov.foreign.ccgslb.com CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A www.gov.foreign.ccgslb.com Standard query response CNAME wac.0b51.edgecastcdn.net CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A wac.0b51.edgecastcdn.net Standard query response CNAME gp1.wac.v2cdn.net A 68.232.35.119 Standard query A gp1.wac.v2cdn.net Standard query response A 68.232.35.119 Standard query DNSKEY <Root> Standard query response DNSKEY DNSKEY RRSIG Standard query DS cn Standard query response Standard query DS net Standard query response DS RRSIG Standard query DNSKEY net Standard query response DNSKEY DNSKEY RRSIG Standard query DS chinacache.net Standard query response Standard query DS com Standard query response DS RRSIG Standard query DNSKEY com Standard query response DNSKEY DNSKEY RRSIG Standard query DS ccgslb.com Standard query response Standard query DS edgecastcdn.net Standard query response Standard query DS v2cdn.net Standard query response An obvious idea to avoid so many roundtrips is to serialize them together. There has been an attempt to standardize such "DNSSEC stapling" [1], however it's incomplete for the general case, mainly due to various intricacies - proofs of non-existence, NSEC3 opt-out zones, TTL handling (see RFC 4035 section 5). References: [1] https://www.ietf.org/mail-archive/web/dane/current/msg02823.html

2 1

[GSOC 2013] Steganography Browser Extension Status Report
by Hareesan 10 Aug '13

10 Aug '13

Hi, In my plan for this week, I supposed to work on image steganography libraries. But due to some latency in decision making about the steganography libraries, I continued working on adding preferences and creating data saving mechanism for keys and filters using sqlite databases. In my next week plan, I will be working on image steganography libraries part of the extension to add image steganography to the extension. -- Hareesan

1 0

Status report - Stream-RTT
by ra 10 Aug '13

10 Aug '13

Hello! Here goes my third status report on reducing the RTT of Tor circuits: First of all I am happy to have received feedback from Damian which I integrated into the RTT-probing script[0][1]. With this script I have already gathered a big amount of data about the RTTs of circuits which I am still evaluating. If there is interest in the raw data, plots or visualization scripts I can make them available online. Best, Robert [0] https://bitbucket.org/ra_/tor- rtt/commits/666e0b173871ba3f699c8bc07bfb156f653adf7a [1] https://bitbucket.org/ra_/tor- rtt/commits/f78f07217cceacce5e9d2509005b244e04436668

1 0

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 09 Aug '13

09 Aug '13

Hello tor-dev, Here goes the status report for the past 2 weeks: - still working at [1] in public branch [2] - rewrote how the filters work, such that a filter currently is an array of function pointers, each function being responsible of setting up the parameter filter for a syscall; also added support such that in the future it is a struct containing the array of function pointers and a linked list of parameters associated with the filter; - I have updated the filters which proved to be a bit more challenging than expected mainly due to the multiple worker thread processes created with clone, which are harder to follow with strace; - as of today, the latest version I have pushed has a more restrictive parameter filter which works for both a normal and ORPort launches. TODO: - fix open syscall problem for file names due to external library opens - investigate socketcall syscalls' parameters failure.. - finish support for multiple filters (beginning of stage 3) - fine-tune filters a bit (end of stage 2) More details may be found here [1]. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9249 [2] https://github.com/cristiantoader/tor-gsoc-capabilities/tree/gsoc-cap-stage2

1 0

[GSoC] Status Report - EvilGenius
by Johannes Fürmann 09 Aug '13

09 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi *, Quite a few things happened in the last few weeks. GSoC midterm, i thought to myself last week, is a great time for some refactoring, so I looked over the code a bit and was able to improve the overall code quality quite a bit. Also I improved the network handling, The network addresses are now actually being set on the VMs and everything is patched together quite nicely, including the connections from the router to the censorship provider. Additionally, I replaced the simple "print" commands with the python logging mechanism and added a dryrun mode that - instead of pulling the whole network up and tearing it down, just prints the vagrantfile, which facilitates testing a lot. Since every machine now has it's resources directory mounted as '/scripts', one can also access shell scripts from the machine's yaml definition. After this weekend, I am going to get started with adding a few modules and implement routing. Have a nice weekend, everyone! Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSBThsAAoJEAgie5o3Q/JpbdUP/RobudUibBGhLHYKYWho5x8h XGBaLhFzVxHfCQhxoIrNP5CbW1OiCb+HQClIFnk4QSnlD189qoK+LzLg/2SuvyVH EnYICDy+GE82F50cRIoZb5yIITKOohQR051ienXIJr8GT1rna50YezOyl4WY5DI+ LIoQ50MR7BdTdT4/BATRK6U3sAs7fVI/VElSHWcCErmNn6PF652B84mQk83+A02c XpkYyEgLZ55tjzq1V+CbcMzYBxnJhPJH8O993mE18AfhaPfnoQvF090xSTsYrm80 GUuRn2Xzw6CHHsbZofdvrS/pzQqHIGreyhKU0lTZxMhH7Lx3zAJ57nO1gpmpH83+ QTNeufwJGUL+vwm5Ci/WT8FGylvoAejvpYjJsyASvAjFMpi5TCs5zBSEYDKQAmFY XMiuAe3R4T/uczpsq0g/T2Y6vH8XpMQ4eadh9IVRjjZI7nRIbjI9hYYWukEsG9/r WSwmsS7ADscbeR6Z5EqLdgdhCgrcBG/jyX8PBTT0hMtoZf03VbPwRXJsFQrhEful KEcoHLCVbG5WUodDZPW9plupni0jefoZek46H0pAzejRzadtmYr9KvseutFC4hcq hArOzsztWqmDJTfoVtQpLgycBnhhz/0ajUpCyxGB5x/OyWj5gO2rVKD++ib7y9/E yR9Wt4fPBrS8X6a1P2JA =2ap3 -----END PGP SIGNATURE-----

1 0

Fwd: Brendan Eich floats idea of Firefox implementing Tor as FF plug-in?
by Bernard Tyers - ei8fdb 08 Aug '13

08 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dave, I have forwarded your mail to the tor-dev list as someone there might be interested/able to help with the boot2gecko (FF OS) work. All the best, Bernard Begin forwarded message: > From: Dave Huseby <dhuseby(a)mozilla.com> > Date: 8 August 2013 19:48:35 GMT+01:00 > To: dev-privacy(a)lists.mozilla.org > Subject: Re: Brendan Eich floats idea of Firefox implementing Tor as FF plug-in? > > So, the tor project maintains their own fork of firefox in the tor > browser bundle. I know that there have been efforts to try to merge > their changes into our repos. AFAIK, the main reason we haven't done so > is because some of their changes modify the default behavior of firefox. > > As a side note, I have a working b2g build of libevent, openssl + > engines, and the tor daemon (all static). I'm in the process of setting > up the a good manifest so that others can recreate it. It won't be > buildable out of the box if you just clone my repos until I set up the > manifest correctly. But I've completed all of the work making > Android.mk files so that the three pieces build as b2g/external/*. If > anybody wants to take a look/help, my repos are here: github.com/dhuseby > All of my changes are in b2g branches in the libevent, openssl, and tor > forks. > > -dave > > On 08/08/2013 09:48 AM, Sid Stamm wrote: >> On 8/8/13 8:52 AM, Bernard Tyers - ei8fdb wrote: >>> "Maybe we should just adopt, support, and bundle Tor in Firefox..." >>> [1] >>> >>> It's early days, and just a comment on Twitter, but I wonder what >>> others have to say. >>> >>> Good or bad idea? I would say (without too much thinking): turned-off >>> by default, but available. Exciting possibilities. >> >> Let me turn it around: what do you think? Why would you like to see this? >> >> I think it's interesting, and at the very least we could work more >> closely with the Tor engineers to make each others software better. >> >> -Sid >> _______________________________________________ >> dev-privacy mailing list >> dev-privacy(a)lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-privacy >> > > _______________________________________________ > dev-privacy mailing list > dev-privacy(a)lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-privacy - -------------------------------------- Bernard / bluboxthief / ei8fdb IO91XM / www.ei8fdb.org -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSA/jZAAoJENsz1IO7MIrrsfIIAIsylP6Q59wGh8JB4ThGIn4b wnddEG6KPCz8vBNgJ1cu6luVXiPLc5ByGRBMAIC0fuNwoP2G5x3JW0HvT9LPztSI giudGcdwocRKWXbfzgY7Pwy5yGwM+SxHAVdlYNTWdz+6CSdzy9kMwpd75u0+TYM1 bWCHY1Z3xhjrrBCwqTLzg3bbU3IWbPImCqGNiDJ5HB475TG7AGRYivM1Ls0+jRRQ 87glawpVvodSTydhg4K8uSwWfJBCEodH82WYBaipiGkaKDX/X/Ha2N7oBNPiQ4IS GX3b6fCjoO9CeRTJa8jRIHcBxbX3jO65jpTUbAb1ITVnPWpRLUr/UbpEfEIqlSM= =eLJC -----END PGP SIGNATURE-----

1 0

Fallback metrics service operator
by Karsten Loesing 08 Aug '13

08 Aug '13

Hi Sebastian, we discussed that you could become the fallback metrics service operator and take over operation whenever I have to go on a four-week round-the-world cruise or in the unlikely case that my application for the one-way trip to Mars [0] goes through. This is awesome! Thanks a lot! Moving this discussion to tor-dev@ in case this is interesting to others. So, you asked what the actual tasks are, and how much time I'd think they'll be taking. Let's start by taking a look at this overview [1] of the various tasks that are performed by metrics services. Going through the various tool names stated in brackets, starting with the ones that I think should have highest priority: - metrics-db-* is where we collect all the fine Tor network data. The cronjob behind metrics-db-R has to run once per hour, or our archives will be missing consensuses and votes published in that hour. The other metrics-db-*'s can handle short downtimes better than metrics-db-R. Beware that this is not the best code you ever read. - metrics-web-* is the metrics website, including the necessary PostgreSQL and Tomcat parts. I'm not spending much time on this codebase anymore, because we should really do something like Thomas does in his Visionion project. But until that's there, metrics-web is all we have. And I think it has quite a few visitors. So, if it breaks, we should fix it ASAP. - task-6498, task-8462, and task-2718 are additions to metrics-web which should be properly integrated into metrics-web.git. I should do this, maybe together with you. - Onionoo powers Atlas, Compass, and a few other tools. It has become quite complex over its 1.5 years of existence. It consists of two parts, a Java backend and a Tomcat frontend. It's actually one of the few codebases I maintain that has pretty high test coverage. I'm trying hard to keep this service running 24/7, and I'm impressed how fast people report if it breaks for just half an hour. Those are the highest priority ones. Looking at the lower priorities: - tor produces descriptors and statistics in its extra-info descriptors that we collect. The only thing I do is nag directory authority operators and the bridge authority operator if something's wrong, so that our descriptor archives will be as complete as possible. - Torperf is our performance measurement tool. You know it from a few years ago when you wrote a Python controller for it. It hasn't changed much since then. I started rewriting it in Twisted, but that's still work in proress. I'm afraid if Torperf breaks, we'll have to fix it. People care about the performance data we gather. - TorDNSEL produces exit lists that we download and archive. If TorDNSEL breaks, metrics-db starts complaining, so we learn that it needs to be fixed. It's always unclear who's going to fix it, but in the end there's always somebody who does. - BridgeDB exports bridge pool assignments that we sanitize and archive. There's currently a bug in BridgeDB making these files not as useful as they could be (#9264). Bugging the BridgeDB maintainer(s) about these things is part of the metrics service operator job, because we care about archives being complete. And finally, here are the services that I'd say are not part of the fallback metrics service operator job: - Atlas is already co-maintained by Philipp since the dev meeting, and he does a great job there so far. - Compass isn't really something I operate. I don't know enough about the web part behind it to fix it if it breaks horribly. I just deploy patches after doing a quick plausibility check, and if they break, I revert. I'd say if it breaks and I'm not around, leave it broken until somebody else fixes it. - DocTor may soon be replaced by a new tool that Damian writes and that will use the new descriptor fetching stuff in Stem. Ideally, we'll shut down DocTor in two months from now, so that's nothing to worry about from a metrics service operation point of view. What did I miss? So, how do we estimate how much time it will take you to get started? Depends on how certain your want to be that you'll be able to handle things if they break. In a perfect world, I'd say that you should set up each service on a different machine and run it for a while. And when we get new hardware in a month or two, we should move services together. I'm aware that this requires a lot of work on both your and my side to understand the code, make it easier to install, and document everything better. But this would also improve the tools a lot. In a maybe more realistic world, I'd say that you should take a look at the codebases and at the service directories on yatei, and then we discuss why things are set up as they are. This should also put you into a fine position to rescue broken services, though you might have to do more research once that happens. Maybe there are more approaches? What do you prefer? Oh, and to be honest, I didn't apply for the Mars thing. ;) All the best, Karsten [0] http://newsfeed.time.com/2013/05/09/78000-people-apply-for-one-way-trip-to-… [1] https://metrics.torproject.org/tools.html

1 0