From 1fb3a60f54d64b82efbb9ccf528e3ef94416a566 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 10 Dec 2010 14:34:26 -0500 Subject: [PATCH 1/7] convert draft pluggable transport proposal to plaintext --- .../ideas/xxx-pluggable-transport.txt | 430 ++++++++++++++++++ 1 file changed, 430 insertions(+) create mode 100644 doc/spec/proposals/ideas/xxx-pluggable-transport.txt diff --git a/doc/spec/proposals/ideas/xxx-pluggable-transport.txt b/doc/spec/proposals/ideas/xxx-pluggable-transport.txt new file mode 100644 index 0000000000..7012b7aded --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-pluggable-transport.txt @@ -0,0 +1,430 @@ +Filename: xxx-pluggable-transport.txt +Title: Pluggable transports for circumvention +Author: Jacob Appelbaum, Nick Mathewson +Created: 15-Oct-2010 +Status: Draft + +Overview + + This is a document about transport plugins; it does not cover + discovery, or bridgedb improvements. Each transport plugin + specification should make clear any external requirements but those + are generally out of scope if they fall into discovery or + infrastructure components. + + We should include a description of how to write a good set of plugins, + how to evaluate and how to classify a plugin. For example, if a plugin + is said to be hard to detect on the wire if you know what it is and + how it works, it should say so. If it's easy, it's still possibly + functional for a given network but perhaps it is not well hidden or + automatically filtered. Detection and blocking are not always the same + thing right off. In both cases, a plugin should be quite clear about + its security claims. + +Target use-cases[a][b] + + Here's some stuff we want to be able to support. We're listing these + in the draft to try to define the problem space. We won't put this + section in the final version. + + 1. The 'obfuscated SSH' superencipherment: + http://github.com/brl/obfuscated-openssh/blob/master/README.obfuscation + + 2. Big P2P-network style transports where instead of connecting to a + bridge at a known IP, you connect to a bridge by a username, a public + key, or whatever. + + 1. We need the ability to have two kinds of proxies - one for + incoming connections and one for outgoing connections. [Sure, but + that's about how we implement stuff arg arg dumb touchpad -NM] + + 1. Probably we want to have the ability to get connections + anyway we'll take them + + 2. So, bridges use the incoming kind, and clients use the ougoing + kind? Sounds right.-N + 1. Probably also we're a multi-plexed incoming kind of Tor + relay - so we should take connections from say localhost's + little helper and also, we should take connections from + external ips. This would be useful to identify though. I think + this is how we would already work as of today. + + 1. You mean, regular non-bridge relays should support this + too? I hadn't considered that. it has seemed pointless + because of IP blocking, but if we have a p2p transport, it + would be useful for regular relays to allow it. Yes -io + + 1. Also it would be nice for stats purposes to ensure that + we know what kinds of connections we're handling, even if + we basically treat them exactly the same. Perhaps Karsten + wants to weigh in on how we should have Tor handle these + things? I guess we'll really fuck up his stats collection + if all of sudden he's getting lots of connections from + 127.0.0.1... + + 1. Various protocol-impersonation tools + 1. NSTX, iodyne, Ozymandns or such, for the lulz. + 1. DNS tunneling of many types - eg: TXT records or the NULL + protocol trick + 1. HTTP -- many kinds are possible, some may even be right + 1. HTTP POST requests are implemented in Firepass + 1. FTP + 1. Perhaps some kind of anonymous ftp login with sending and + receiving of data would be useful? + 1. Lots to think about before designing off the cuff crappy + protocol covert channels + 1. NTP + 1. Hardly anyone knows about NTP these days - it's almost always + outbound allowed and it's usually not well inspected + 1. That makes it good for short-term circumvention, but bad + for long-term hiding. + 1. Triangle-boy + 2. IPSec look-alike + 3. UDP + 4. IPv6 + 1. A forged-RST-ignoring tool + 1. A forged-RST-ignoring tool that pretends that it is getting all + of its connections closed and retrying all the time, when really + it is just carrying on with business as usual. Hooray for + crypto. + 1. Perhaps it's a good idea to mention CCTT? + 1. What else goes here? + 1. We should ask Nextgens about protocol filters from Freenet + 2. http://gray-world.net/papers.shtml + 3. http://gray-world.net/pr_cook_cc.shtml + 4. http://gray-world.net/pr_firepass.shtml + 5. We should ensure we cover the topics and lessons learned from + "FIREWALL RESISTANCE TO METAFEROGRAPHY IN NETWORK COMMUNICATIONS" + - see + https://ritdml.rit.edu/bitstream/handle/1850/12272/RSavacoolThesis5-21-2010.pdf + + Here's some stuff that seems out-of-scope: + + 1. A generic firewall-breaker that works with all Tor nodes and + bridges. Like, if you're using a VPN to get through your firewall, + and it lets you connect to any Tor node, you can just use it without + any special plug-in support. I think this spec is just for stuff + that requires buy-in from the server side of the connection. Agreed? + + 1. Yeah - I think we should simply codify the proxy stuff to ensure + that we plan to remain pluggable for incoming and outgoing connections + in some formal way. + + I'm uncertain if we want to support stuff like: + + 1. An ssh tunnel that uses openssh to tunnel raw tor packets, with no + actual TLS going on underneath. Promising, but risky. -NM + + 1. I think there isn't much to gain by doing this but perhaps so - we + are too dependent on TLS and our certs are trivial to fingerprint -io + + 1. Also, Tor-over-TLS-tunneled-over-SSH looks even weirder than + Tor-over-SSH. -N + + 2. It might be nice to allow certs [cn] fields to be configurable by + bridge nodes? -io + + 1. If we allowed "raw traffic" transports, a transport could get this + trivially by implementing TLS with the right certs. -NM + + 1. perhaps we just want a "raw traffic port" where we connect to pass + around cells? thoughts? + + 1. A bridge-discovery-and-round-robin p2p tool that connects you to a + randomly chosen one of an unknown number of bridges. + + 1. Stackable plugins + 1. Tor over DNS over HTTP Post over Obfuscated Tor to reach the Tor + network to read a copy of uncensored Google News. + 1. Christ, what the fuck world are we building? Or even more, + what kind of world are we resisting? + 1. More like RST-drop plus sshobfs over HTTP over VPN. + + +Goals & Motivation + + Frequently, people want to try a novel circumvention method to help + users connect to Tor bridges. Some of these methods are already + pretty easy to deploy: if the user knows an unblocked VPN or open + SOCKS proxy, they can just use that with the Tor client today. + + Less easy to deploy are methods that require participation by both the + client and the bridge. In order of increasing sophistication, we + might want to support: + + 1. A protocol obfuscation tool that transforms the output of a TLS + connection into something that looks like HTTP as it leaves the client, + and back to TLS as it arrives at the bridge. + 2. An additional authentication step that a client would need to + perform for a given bridge before being allowed to connect. + 3. An information passing system that uses a side-channel in some + existing protocol to convey traffic between a client and a bridge + without the two of them ever communicating directly. + 4. A set of clients to tunnel client->bridge traffic over an existing + large p2p network, such that the bridge is known by an identifier + in that network rather than by an IP address. + + We could in theory support these almost fine with Tor as it stands + today: every Tor client can take a SOCKS proxy to use for its outgoing + traffic, so a suitable client proxy could handle the client's traffic + and connections on its behalf, while a corresponding program on the + bridge side could handle the bridge's side of the protocol + transformation. Nevertheless, there are some reasons to add support + for transportation plugins to Tor itself: + + 1. It would be good for bridges to have a standard way to advertise + which transports they support, so that clients can have multiple + local transport proxies, and automatically use the right one for + the right bridge. + + 2. There are some changes to our architecture that we'll need for a + system like this to work. For testing purposes, if a bridge blocks + off its regular ORPort and instead has an obfuscated ORPort, the + bridge authority has no way to test it. Also, unless the bridge + has some way to tell that the bridge-side proxy at 127.0.0.1 is not + the origin of all the connections it is relaying, it might decide + that there are too many connections from 127.0.0.1, and start + paring them down to avoid a DoS. + + 3. + 4. (what else?) + +Non-Goals + + We're not going to talk about automatic verification of plugin + correctness and safety via sandboxing, proof-carrying code, or + whatever. + + We need to do more with discovery and distribution, but that's not + what this proposal is about. We're pretty convinced that the problems + are sufficiently orthogonal that we should be fine so long as we don't + preclude a single program from implementing both transport and + discovery extensions. + + This proposal is not about what transport plugins are the best ones + for people to write. + + We've considered issues involved with completely replacing Tor's TLS + with another encryption layer, rather than layering it inside the + obfuscation layer. We describe how to do this in an appendix to the + current proposal, though we are not currently sure whether it's a good + idea to implement. + +Design overview + + Clients run one or more "Transport client" programs that act like + SOCKS proxies. They accept connections on localhost on different + ports. Each one implements one or more transport methods. Parameters + are passed from Tor inside the regular username/password parts of the + SOCKS protocol. + + Bridges (and maybe relays) run one or more programs that act like + stunnel-server (or whatever the option is): they get connections from + the network (typically by listening for connections on the network) + and relay them to the Bridge's real ORPort. + + 1. The bridge needs to know which methods these servers support + + 1. The bridge needs to advertise this fact some way that the clients + will find out about it--probably by sticking it in its bridge + descriptor so that the bridgedb can find out and see that the clients + get informed. + + 2. Somebody needs to launch these programs + + 3. The bridge may want to just not have a public ORPort at all. + + 4. The bridge may not want to advertise a real IP at all + + 5. The bridge will want to find out from the program any client + identification information it can get (IP, etc) to implement rules + about max clients at once + + Any methods that are wildly successful, we can bake into Tor. + +Proposed terminology: + + Transport protocol: + Transport proxy: + +Specifications: Client behavior + + Bridge lines can now follow the extended format "bridge method + address:port [[keyid=]id-fingerprint] [k=v] [k=v] [k=v]". To connect + to such a bridge, a client must open a local connection to the SOCKS + proxy for "method", and ask it to connect to address:port. If + [id-fingerprint] is provided, it should expect the public identity key + on the TLS connection to match the digest provided in + [id-fingerprint]. If any [k=v] items are provided, they are + configuration parameters for the proxy: Tor should separate them with + NUL bytes and put them user and password fields of the request, + splitting them across the fields as necessary. The "id-fingerprint" + field is always provided in a field named "keyid", if it was given. + + + example: if the bridge line is "bridge trebuchet www.example.com:3333 + rocks=20 height=5.6m" then, if the Tor client knows that the + ‘trebuchet' method is provided by a SOCKS5 proxy on 127.0.0.1:19999, + it should connect to that proxy, ask it to connect to www.example.com, + and provide the string "rocks=20\0height=5.6m" as the username, the + password, or split across the username and password. + + + There are two ways to tell Tor clients about protocol proxies: + external proxies and managed proxies. An external proxy is configured + with "Transport trebuchet socks5 127.0.0.1:9999". This tells Tor that + another program is already running to handle ‘trubuchet' connections, + and Tor doesn't need to worry about it. A managed proxy is configured + with "Transport trebuchet /usr/libexec/tor-proxies/trebuchet + [options]", and tells Tor to launch an external program on-demand to + provide a socks proxy for ‘trebuchet' connections. The Tor client only + launches one instance of each external program, even if the same + executable is listed for more than one method. + + The same program can implement a managed or an external proxy: it just + needs to take an argument saying which one to be. + + [I don't like the terminology here. We should pick better words before + this "external/managed" stuff catches on. Also, to most users a + "proxy" is a computer that relays stuff for them, not a local program + on their computer. -NM I think we should go with Helper of some kind + as it's less technically overloaded and more friendly feeling - io + "Helper" is too overloaded already. -NM] + +Client proxy behavior + + When launched from the command-line by a Tor client, a transport + proxy needs to tell Tor which methods and ports it supports. It does + this by printing one or more METHOD: lines to its stdout. These look + like CMETHOD: trebuchet SOCKS5 127.0.0.1:19999 ARGS:rocks,height + OPT-ARGS:tensile-strength + + The ARGS field lists mandatory parameters that must appear in every + bridge line for this method. The OPT-ARGS field lists optional + parameters. If no ARGS or OPT-ARGS field is provided, Tor should not + check the parameters in bridge lines for this method. + + The proxy should print a single "METHODS:DONE" line after it is + finished telling Tor about the methods it provides. + + [Should methods be versionable? Can they be? -nm I think probably? + -io Then how? -nm] + + The transport proxy MUST exit cleanly when it receives a SIGTERM from + Tor. + + The Tor client MUST ignore lines beginning with a keyword and a colon + if it does not recognize the keyword. + + In the future, if we need a control mechanism, we can use the + stdin/stdout from Tor to the transport proxy. + +Transport proxy requirements + + A transport proxy MUST handle SOCKS connect requests using the SOCKS + version it advertises. + +Server proxy behavior + + [So, we can have this work like client proxies, where the bridge + launches some programs, and they tell the bridge, "I am giving you + method X with parameters Y"? Do you have to take all the methods? If + not, which do you specify?] + + [Do we allow programs that get started independently?] + + [We'll need to figure out how this works with port forwarding. Is + port forwarding the bridge's problem, the proxy's problem, or some + combination of the two?] + + [If we're using the bridge authority/bridgedb system for distributing + bridge info, the right place to advertise bridge lines is probably + the extrainfo document. We also need a way to tell the bridge + authority "don't give out a default bridge line for me"] + +Server behavior + +Bridge authority behavior + +Implementation plan + + Finish the design work here. + Clean up all the inline conversations to just get summarized by the + conclusions they arrived at. + + Turn this into a draft proposal + + Circulate and discuss on or-dev + + (Use Cinderblock Of Loving Correction to reeducate anybody who tries + to divert discussion of how pluggable transports should work into + discussion of what is the best possible transport, or whatever.) + + We should ship a couple of null plugin implementations in one or two + popular, portable languages so that people get an idea of how to + write the stuff. + + 1. We should have one that's just a proof of concept that does + nothing but transfer bytes back and forth. + + 1. We should not do a rot13 one. + + 2. We should implement a basic proxy that does not transform the bytes at all + + 1. We should implement DNS or HTTP using other software (as goodell + did years ago with DNS) as an example of wrapping existing code into + our plugin model. + + 2. The obfuscated-ssh superencipherment is pretty trivial and pretty + useful. It makes the protocol stringwise unfingerprintable. + + 1. Nick needs to be told firmly not to bikeshed the obfuscated-ssh + superencipherment too badly + + 1. Go ahead, bikeshed my day + + 1. If we do a raw-traffic proxy, openssh tunnels would be the logical choice. + +Appendix: recommendations for transports + + Be free/open-source software. Also, if you think your code might + someday do so well at circumvention that it should be implemented + inside Tor, it should use the same license as Tor. + + Use libraries that Tor already requires. (You can rely on openssl and + libevent being present if current Tor is present.) + + Be portable: most Tor users are on Windows, and most Tor developers + are not, so designing your code for just one of these platforms will + make it either get a small userbase, or poor auditing. + + Think secure: if your code is in a C-like language, and it's hard to + read it and become convinced it's safe then, it's probably not safe. + + Think small: we want to minimize the bytes that a Windows user needs + to download for a transport client. + + Specify: if you can't come up with a good explanation + + Avoid security-through-obscurity if possible. Specify. + + Resist trivial fingerprinting: There should be no good string or regex + to search for to distinguish your protocol from protocols permitted by + censors. + + Imitate a real profile: There are many ways to implement most + protocols -- and in many cases, most possible variants of a given + protocol won't actually exist in the wild. + +Appendix: Raw-traffic transports + + This section describes an optional extension to the proposal above. + + +[a]I agree that we should remove this section - perhaps we should also save the links and move them to the possible plugin examples? - ioerror + +[b]This whole section should get removed from the final thing. I tried to summarize broad themes in the Motivations section below. - NM + +[c]That doesn't really help - does it? Or do you mean that the Tor should set the CN to be say, the IP or hostname of the relay? - ioerror + +The "Address" field when we have it. After that, the hostname if we know it. After that, do a PTR lookup on our IP. After that, use our IP. -NM From 2118028c5074d6aba482377d976674941ac0d9fe Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 10 Dec 2010 16:55:32 -0500 Subject: [PATCH 2/7] start reformatting and editing the pluggable-transport proposal --- .../ideas/xxx-pluggable-transport.txt | 310 ++++++------------ 1 file changed, 93 insertions(+), 217 deletions(-) diff --git a/doc/spec/proposals/ideas/xxx-pluggable-transport.txt b/doc/spec/proposals/ideas/xxx-pluggable-transport.txt index 7012b7aded..4b9427027b 100644 --- a/doc/spec/proposals/ideas/xxx-pluggable-transport.txt +++ b/doc/spec/proposals/ideas/xxx-pluggable-transport.txt @@ -6,142 +6,21 @@ Status: Draft Overview + This proposal describes a way to decouple protocol-level obfuscation + from the core Tor protocol in order to better resist client-bridge + censorship. Our approach is to specify a means to add pluggable + transport implementations to Tor clients and bridges so that they can + negotiate a superencipherment for the Tor protocol. + +Scope + This is a document about transport plugins; it does not cover - discovery, or bridgedb improvements. Each transport plugin - specification should make clear any external requirements but those - are generally out of scope if they fall into discovery or - infrastructure components. + discovery improvements, or bridgedb improvements. While these + requirements might be solved by a program that also functions as a + transport plugin, this proposal only covers the requirements and + operation of transport plugins. - We should include a description of how to write a good set of plugins, - how to evaluate and how to classify a plugin. For example, if a plugin - is said to be hard to detect on the wire if you know what it is and - how it works, it should say so. If it's easy, it's still possibly - functional for a given network but perhaps it is not well hidden or - automatically filtered. Detection and blocking are not always the same - thing right off. In both cases, a plugin should be quite clear about - its security claims. - -Target use-cases[a][b] - - Here's some stuff we want to be able to support. We're listing these - in the draft to try to define the problem space. We won't put this - section in the final version. - - 1. The 'obfuscated SSH' superencipherment: - http://github.com/brl/obfuscated-openssh/blob/master/README.obfuscation - - 2. Big P2P-network style transports where instead of connecting to a - bridge at a known IP, you connect to a bridge by a username, a public - key, or whatever. - - 1. We need the ability to have two kinds of proxies - one for - incoming connections and one for outgoing connections. [Sure, but - that's about how we implement stuff arg arg dumb touchpad -NM] - - 1. Probably we want to have the ability to get connections - anyway we'll take them - - 2. So, bridges use the incoming kind, and clients use the ougoing - kind? Sounds right.-N - 1. Probably also we're a multi-plexed incoming kind of Tor - relay - so we should take connections from say localhost's - little helper and also, we should take connections from - external ips. This would be useful to identify though. I think - this is how we would already work as of today. - - 1. You mean, regular non-bridge relays should support this - too? I hadn't considered that. it has seemed pointless - because of IP blocking, but if we have a p2p transport, it - would be useful for regular relays to allow it. Yes -io - - 1. Also it would be nice for stats purposes to ensure that - we know what kinds of connections we're handling, even if - we basically treat them exactly the same. Perhaps Karsten - wants to weigh in on how we should have Tor handle these - things? I guess we'll really fuck up his stats collection - if all of sudden he's getting lots of connections from - 127.0.0.1... - - 1. Various protocol-impersonation tools - 1. NSTX, iodyne, Ozymandns or such, for the lulz. - 1. DNS tunneling of many types - eg: TXT records or the NULL - protocol trick - 1. HTTP -- many kinds are possible, some may even be right - 1. HTTP POST requests are implemented in Firepass - 1. FTP - 1. Perhaps some kind of anonymous ftp login with sending and - receiving of data would be useful? - 1. Lots to think about before designing off the cuff crappy - protocol covert channels - 1. NTP - 1. Hardly anyone knows about NTP these days - it's almost always - outbound allowed and it's usually not well inspected - 1. That makes it good for short-term circumvention, but bad - for long-term hiding. - 1. Triangle-boy - 2. IPSec look-alike - 3. UDP - 4. IPv6 - 1. A forged-RST-ignoring tool - 1. A forged-RST-ignoring tool that pretends that it is getting all - of its connections closed and retrying all the time, when really - it is just carrying on with business as usual. Hooray for - crypto. - 1. Perhaps it's a good idea to mention CCTT? - 1. What else goes here? - 1. We should ask Nextgens about protocol filters from Freenet - 2. http://gray-world.net/papers.shtml - 3. http://gray-world.net/pr_cook_cc.shtml - 4. http://gray-world.net/pr_firepass.shtml - 5. We should ensure we cover the topics and lessons learned from - "FIREWALL RESISTANCE TO METAFEROGRAPHY IN NETWORK COMMUNICATIONS" - - see - https://ritdml.rit.edu/bitstream/handle/1850/12272/RSavacoolThesis5-21-2010.pdf - - Here's some stuff that seems out-of-scope: - - 1. A generic firewall-breaker that works with all Tor nodes and - bridges. Like, if you're using a VPN to get through your firewall, - and it lets you connect to any Tor node, you can just use it without - any special plug-in support. I think this spec is just for stuff - that requires buy-in from the server side of the connection. Agreed? - - 1. Yeah - I think we should simply codify the proxy stuff to ensure - that we plan to remain pluggable for incoming and outgoing connections - in some formal way. - - I'm uncertain if we want to support stuff like: - - 1. An ssh tunnel that uses openssh to tunnel raw tor packets, with no - actual TLS going on underneath. Promising, but risky. -NM - - 1. I think there isn't much to gain by doing this but perhaps so - we - are too dependent on TLS and our certs are trivial to fingerprint -io - - 1. Also, Tor-over-TLS-tunneled-over-SSH looks even weirder than - Tor-over-SSH. -N - - 2. It might be nice to allow certs [cn] fields to be configurable by - bridge nodes? -io - - 1. If we allowed "raw traffic" transports, a transport could get this - trivially by implementing TLS with the right certs. -NM - - 1. perhaps we just want a "raw traffic port" where we connect to pass - around cells? thoughts? - - 1. A bridge-discovery-and-round-robin p2p tool that connects you to a - randomly chosen one of an unknown number of bridges. - - 1. Stackable plugins - 1. Tor over DNS over HTTP Post over Obfuscated Tor to reach the Tor - network to read a copy of uncensored Google News. - 1. Christ, what the fuck world are we building? Or even more, - what kind of world are we resisting? - 1. More like RST-drop plus sshobfs over HTTP over VPN. - - -Goals & Motivation +Motivation Frequently, people want to try a novel circumvention method to help users connect to Tor bridges. Some of these methods are already @@ -153,8 +32,8 @@ Goals & Motivation might want to support: 1. A protocol obfuscation tool that transforms the output of a TLS - connection into something that looks like HTTP as it leaves the client, - and back to TLS as it arrives at the bridge. + connection into something that looks like HTTP as it leaves the + client, and back to TLS as it arrives at the bridge. 2. An additional authentication step that a client would need to perform for a given bridge before being allowed to connect. 3. An information passing system that uses a side-channel in some @@ -186,8 +65,20 @@ Goals & Motivation that there are too many connections from 127.0.0.1, and start paring them down to avoid a DoS. - 3. - 4. (what else?) + 3. Censorship and anticensorship techniques often evolve faster than + the typical Tor release cycle. As such, it's a good idea to + provide ways to test out new anticensorship mechanisms on a more + rapid basis. + + 4. Transport obfuscation is a relatively distinct problem + from the other privacy problems that Tor tries to solve, and it + requires a fairly distinct skill-set from hacking the rest of Tor. + By decoupling transport obfuscation from the Tor core, we hope to + encourage people working on transport obfuscation who would + otherwise not be interested in hacking Tor. + + 5. Finally, we hope that defining a generic transport obfuscation plugin + mechanism will be useful to other anticensorship projects. Non-Goals @@ -202,7 +93,8 @@ Non-Goals discovery extensions. This proposal is not about what transport plugins are the best ones - for people to write. + for people to write. We do, however, make some general + recommendations for plugin authors in an appendix. We've considered issues involved with completely replacing Tor's TLS with another encryption layer, rather than layering it inside the @@ -210,43 +102,39 @@ Non-Goals current proposal, though we are not currently sure whether it's a good idea to implement. + We deliberately reject any design that would involve linking more code + into Tor's process space. + Design overview - Clients run one or more "Transport client" programs that act like - SOCKS proxies. They accept connections on localhost on different - ports. Each one implements one or more transport methods. Parameters - are passed from Tor inside the regular username/password parts of the - SOCKS protocol. + To write a new transport protocol, an implementer must provide two + pieces: a "Client Proxy" to run at the initiator side, and a "Server + Proxy" to run a the server side. These two pieces may or may not be + implemented by the same program. - Bridges (and maybe relays) run one or more programs that act like - stunnel-server (or whatever the option is): they get connections from - the network (typically by listening for connections on the network) - and relay them to the Bridge's real ORPort. + Each client may run any number of Client Proxies. Each one acts like + a SOCKS proxy that accepts accept connections on localhost. Each one + runs on a different port, and implements one or more transport + methods. If the protocol has any parameters, they passed from Tor + inside the regular username/password parts of the SOCKS protocol. - 1. The bridge needs to know which methods these servers support + Bridges (and maybe relays) may run any number of Server Proxies: these + programs provide an interface like stunnel-server (or whatever the + option is): they get connections from the network (typically by + listening for connections on the network) and relay them to the + Bridge's real ORPort. - 1. The bridge needs to advertise this fact some way that the clients - will find out about it--probably by sticking it in its bridge - descriptor so that the bridgedb can find out and see that the clients - get informed. + To configure one of these programs, it should be sufficient simply to + list it in your torrc. The program tells Tor which transports it + provides. - 2. Somebody needs to launch these programs - - 3. The bridge may want to just not have a public ORPort at all. - - 4. The bridge may not want to advertise a real IP at all - - 5. The bridge will want to find out from the program any client - identification information it can get (IP, etc) to implement rules - about max clients at once + Bridges (and maybe relays) report in their descriptors which transport + protocols they support. This information can be copied into bridge + lines. Bridges using a transport protocol may have multiple bridge + lines. Any methods that are wildly successful, we can bake into Tor. -Proposed terminology: - - Transport protocol: - Transport proxy: - Specifications: Client behavior Bridge lines can now follow the extended format "bridge method @@ -261,43 +149,38 @@ Specifications: Client behavior splitting them across the fields as necessary. The "id-fingerprint" field is always provided in a field named "keyid", if it was given. - - example: if the bridge line is "bridge trebuchet www.example.com:3333 - rocks=20 height=5.6m" then, if the Tor client knows that the - ‘trebuchet' method is provided by a SOCKS5 proxy on 127.0.0.1:19999, - it should connect to that proxy, ask it to connect to www.example.com, - and provide the string "rocks=20\0height=5.6m" as the username, the - password, or split across the username and password. - + Example: if the bridge line is "bridge trebuchet www.example.com:3333 + rocks=20 height=5.6m" AND if the Tor client knows that the + 'trebuchet' method is provided by a SOCKS5 proxy on + 127.0.0.1:19999, the client should connect to that proxy, ask it to + connect to www.example.com, and provide the string + "rocks=20\0height=5.6m" as the username, the password, or split + across the username and password. There are two ways to tell Tor clients about protocol proxies: external proxies and managed proxies. An external proxy is configured - with "Transport trebuchet socks5 127.0.0.1:9999". This tells Tor that - another program is already running to handle ‘trubuchet' connections, - and Tor doesn't need to worry about it. A managed proxy is configured - with "Transport trebuchet /usr/libexec/tor-proxies/trebuchet - [options]", and tells Tor to launch an external program on-demand to - provide a socks proxy for ‘trebuchet' connections. The Tor client only - launches one instance of each external program, even if the same - executable is listed for more than one method. + with "ClientTransportPlugin trebuchet socks5 127.0.0.1:9999". This + tells Tor that another program is already running to handle + 'trubuchet' connections, and Tor doesn't need to worry about it. A + managed proxy is configured with "ClientTransportPlugin trebuchet + /usr/libexec/tor-proxies/trebuchet [options]", and tells Tor to launch + an external program on-demand to provide a socks proxy for 'trebuchet' + connections. The Tor client only launches one instance of each + external program, even if the same executable is listed for more than + one method. The same program can implement a managed or an external proxy: it just needs to take an argument saying which one to be. - [I don't like the terminology here. We should pick better words before - this "external/managed" stuff catches on. Also, to most users a - "proxy" is a computer that relays stuff for them, not a local program - on their computer. -NM I think we should go with Helper of some kind - as it's less technically overloaded and more friendly feeling - io - "Helper" is too overloaded already. -NM] - Client proxy behavior When launched from the command-line by a Tor client, a transport proxy needs to tell Tor which methods and ports it supports. It does - this by printing one or more METHOD: lines to its stdout. These look - like CMETHOD: trebuchet SOCKS5 127.0.0.1:19999 ARGS:rocks,height - OPT-ARGS:tensile-strength + this by printing one or more CMETHOD: lines to its stdout. These look + like + + CMETHOD: trebuchet SOCKS5 127.0.0.1:19999 ARGS:rocks,height \ + OPT-ARGS:tensile-strength The ARGS field lists mandatory parameters that must appear in every bridge line for this method. The OPT-ARGS field lists optional @@ -307,9 +190,6 @@ Client proxy behavior The proxy should print a single "METHODS:DONE" line after it is finished telling Tor about the methods it provides. - [Should methods be versionable? Can they be? -nm I think probably? - -io Then how? -nm] - The transport proxy MUST exit cleanly when it receives a SIGTERM from Tor. @@ -319,14 +199,26 @@ Client proxy behavior In the future, if we need a control mechanism, we can use the stdin/stdout from Tor to the transport proxy. -Transport proxy requirements - A transport proxy MUST handle SOCKS connect requests using the SOCKS version it advertises. + Tor clients SHOULD NOT use any method from a client proxy unless it + is both listed as a possible method for that proxy in torrc, and it + is listed by the proxy as a method it supports. + + [XXXX say something about versioning.] + +Server behavior + + Server proxies are configured similarly to client proxies. + + + Server proxy behavior - [So, we can have this work like client proxies, where the bridge + + + [so, we can have this work like client proxies, where the bridge launches some programs, and they tell the bridge, "I am giving you method X with parameters Y"? Do you have to take all the methods? If not, which do you specify?] @@ -348,17 +240,9 @@ Bridge authority behavior Implementation plan - Finish the design work here. - Clean up all the inline conversations to just get summarized by the - conclusions they arrived at. - Turn this into a draft proposal - Circulate and discuss on or-dev - - (Use Cinderblock Of Loving Correction to reeducate anybody who tries - to divert discussion of how pluggable transports should work into - discussion of what is the best possible transport, or whatever.) + Circulate and discuss on or-dev. We should ship a couple of null plugin implementations in one or two popular, portable languages so that people get an idea of how to @@ -419,12 +303,4 @@ Appendix: recommendations for transports Appendix: Raw-traffic transports This section describes an optional extension to the proposal above. - - -[a]I agree that we should remove this section - perhaps we should also save the links and move them to the possible plugin examples? - ioerror - -[b]This whole section should get removed from the final thing. I tried to summarize broad themes in the Motivations section below. - NM - -[c]That doesn't really help - does it? Or do you mean that the Tor should set the CN to be say, the IP or hostname of the relay? - ioerror - -The "Address" field when we have it. After that, the hostname if we know it. After that, do a PTR lookup on our IP. After that, use our IP. -NM + We are not sure whether it is a good idea. From 462185d1804620ca1954baafaad3f8dc1aa02080 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 13 Dec 2010 23:39:54 -0500 Subject: [PATCH 3/7] Add a proposal-ideas document for crypto migration. --- .../proposals/ideas/xxx-crypto-migration.txt | 382 ++++++++++++++++++ 1 file changed, 382 insertions(+) create mode 100644 doc/spec/proposals/ideas/xxx-crypto-migration.txt diff --git a/doc/spec/proposals/ideas/xxx-crypto-migration.txt b/doc/spec/proposals/ideas/xxx-crypto-migration.txt new file mode 100644 index 0000000000..baebfb527d --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-crypto-migration.txt @@ -0,0 +1,382 @@ + +Title: Initial thoughts on migrating Tor to new cryptography +Author: Nick Mathewson +Created: 12 December 2010 + +1. Introduction + + Tor currently uses AES-128, RSA-1024, and SHA1. Even though these + ciphers were a decent choice back in 2003, and even though attacking + these algorithms is by no means the best way for a well-funded + adversary to attack users (correlation attacks are still cheaper, even + with pessimistic assumptions about the security of each cipher), we + will want to move to better algorithms in the future. Indeed, if + migrating to a new ciphersuite were simple, we would probably have + already moved to RSA-1024/AES-128/SHA256 or something like that. + + So it's a good idea to start figuring out how we can move to better + ciphers. Unfortunately, this is a bit nontrivial, so before we start + doing the design work here, we should start by examining the issues + involved. Robert Ransom and I both decided to spend this weekend + writing up documents of this type so that we can see how much two + people working independently agree on. I know more Tor than Robert; + Robert knows far more cryptography than I do. With luck we'll + complement each other's work nicely. + + A note on scope: This document WILL NOT attempt to pick a new cipher + or set of ciphers. Instead, it's about how to migrate to new ciphers + in general. Any algorithms mentioned other than those we use today + are just for illustration. + + Also, I don't much consider the importance of updating each particular + usage; only the methods that you'd use to do it. + + Also, this isn't a complete proposal. + +2. General principles and tricks + + Before I get started, let's talk about some general design issues. + +2.1. Many algorithms or few? + + Protocols like TLS and OpenPGP allow a wide choice of cryptographic + algorithms; so long as the sender and receiver (or the responder and + initiator) have at least one mutually acceptable algorithm, they can + converge upon it and send each other messages. + + This isn't the best choice for anonymity designs. If two clients + support a different set of algorithms, then an attacker can tell them + apart. A protocol with N ciphersuites would in principle split + clients into 2**N-1 sets. (In practice, nearly all users will use the + default, and most users who choose _not_ to use the default will do so + without considering the loss of anonymity. See "Anonymity Loves + Company: Usability and the Network Effect".) + + On the other hand, building only one ciphersuite into Tor has a flaw + of its own: it has proven difficult to migrate to another one. So + perhaps instead of specifying only a single new ciphersuite, we should + specify more than one, with plans to switch over (based on a flag in + the consensus or some other secure signal) once the first choice of + algorithms start looking iffy. This switch-based approach would seem + especially easy for parameterizable stuff like key sizes. + +2.2. Waiting for old clients and servers to upgrade + + The easiest way to implement a shift in algorithms would be to declare + a "flag day": once we have the new versions of the protocols + implemented, pick a day by which everybody must upgrade to the new + software. Before this day, the software would have the old behavior; + after this way, it would use the improved behavior. + + Tor tries to avoid flag days whenever possible; they have well-known + issues. First, since a number of our users don't automatically + update, it can take a while for people to upgrade to new versions of + our software. Second and more worryingly, it's hard to get adequate + testing for new behavior that is off-by-default. Flag days in other + systems have been known to leave whole networks more or less + inoperable for months; we should not trust in our skill to avoid + similar problems. + + So if we're avoiding flag days, what can we do? + + * We can add _support_ for new behavior early, and have clients use it + where it's available. (Clients know the advertised versions of the + Tor servers they use-- but see 2.3 below for a danger here, and 2.4 + for a bigger danger.) + + * We can remove misfeatures that _prevent_ deployment of new + behavior. For instance, if a certain key length has an arbitrary + 1024-bit limit, we can remove that arbitrary limitation. + + * Once an optional new behavior is ubiquitous enough, the authorities + can stop accepting descriptors from servers that do not have it + until they upgrade. + + It is far easier to remove arbitrary limitations than to make other + changes; such changes are generally safe to back-port to older stable + release series. But in general, it's much better to avoid any plans + that require waiting for any version of Tor to no longer be in common + use: a stable release can take on the order of 2.5 years to start + dropping off the radar. Thandy might fix that, but even if a perfect + Thandy release comes out tomorrow, we'll still have lots of older + clients and relays not using it. + + We'll have to approach the migration problem on a case-by-case basis + as we consider the algorithms used by Tor and how to change them. + +2.3. Early adopters and other partitioning dangers + + It's pretty much unavoidable that clients running software that speak + the new version of any protocol will be distinguishable from those + that cannot speak the new version. This is inevitable, though we + could try to minimize the number of such partitioning sets by having + features turned on in the same release rather than one-at-a-time. + + Another option here is to have new protocols controlled by a + configuration tri-state with values "on", "off", and "auto". The + "auto" value means to look at the consensus to decide wither to use + the feature; the other two values are self-explanatory. We'd ship + clients with the feature set to "auto" by default, with people only + using "on" for testing. + + If we're worried about early client-side implementations of a protocol + turning out to be broken, we can have the consensus value say _which_ + versions should turn on the protocol. + +2.4. Avoid whole-circuit switches + + One risky kind of protocol migration is a feature that gets used only + when all the routers in a circuit support it. If such a feature is + implemented by few relays, then each relay learns a lot about the rest + of the path by seeing it used. On the other hand, if the feature is + implemented by most relays, then a relay learns a lot about the rest of + the path when the feature is *not* used. + + It's okay to have a feature that can be only used if two consecutive + routers in the patch support it: each router knows the ones adjacent + to it, after all, so knowing what version of Tor they're running is no + big deal. + +2.5. The Second System Effect rears its ugly head + + Any attempt at improving Tor's crypto is likely to involve changes + throughout the Tor protocol. We should be aware of the risks of + falling into what Fred Brooks called the "Second System Effect": when + redesigning a fielded system, it's always tempting to try to shovel in + every possible change that one ever wanted to make to it. + + This is a fine time to make parts of our protocol that weren't + previously versionable into ones that are easier to upgrade in the + future. This probably _isn't_ time to redesign every aspect of the + Tor protocol that anybody finds problematic. + +2.6. Low-hanging fruit and well-lit areas + + Not all parts of Tor are tightly covered. If it's possible to upgrade + different parts of the system at different rates from one another, we + should consider doing the stuff we can do easier, earlier. + + But remember the story of the policeman who finds a drunk under a + streetlamp, staring at the ground? The cop asks, "What are you + doing?" The drunk says, "I'm looking for my keys!" "Oh, did you drop + them around here?" says the policeman. "No," says the drunk, "But the + light is so much better here!" + + Or less proverbially: Simply because a change is easiest, does not + mean it is the best use of our time. We should avoid getting bogged + down solving the _easy_ aspects of our system unless they happen also + to be _important_. + +2.7. Nice safe boring codes + + Let's avoid, to the extent that we can: + - being the primary user of any cryptographic construction or + protocol. + - anything that hasn't gotten much attention in the literature. + - anything we would have to implement from scratch + - anything without a nice BSD-licensed C implementation + + Some times we'll have the choice of a more efficient algorithm or a + more boring & well-analyzed one. We should not even consider trading + conservative design for efficiency unless we are firmly in the + critical path. + +2.8. Key restrictions + + Our spec says that RSA exponents should be 65537, but our code never + checks for that. If we want to bolster resistance against collision + attacks, we could check this requirement. To the best of my + knowledge, nothing violates it except for tools like "shallot" that + generate cute memorable .onion names. If we want to be nice to + shallot users, we could check the requirement for everything *except* + hidden service identity keys. + +3. Aspects of Tor's cryptography, and thoughts on how to upgrade them all + +3.1. Link cryptography + + Tor uses TLS for its link cryptography; it is easy to add more + ciphersuites to the acceptable list, or increase the length of + link-crypto public keys, or increase the length of the DH parameter, + or sign the X509 certificates with any digest algorithm that OpenSSL + clients will support. Current Tor versions do not check any of these + against expected values. + + The identity key used to sign the second certificate in the current + handshake protocol, however, is harder to change, since it needs to + match up with what we see in the router descriptor for the router + we're connecting to. See notes on router identity below. So long as + the certificate chain is ultimately authenticated by a RSA-1024 key, + it's not clear whether making the link RSA key longer on its own + really improves matters or not. + + Recall also that for anti-fingerprinting reasons, we're thinking of + revising the protocol handshake some time in the 0.2.3.x timeframe. + If we do that, that might be a good time to make sure that we aren't + limited by the old identity key size. + +3.2. Circuit-extend crypto + + Currently, our code requires RSA onion keys to be 1024 bits long. + Additionally, current nodes will not deliver an EXTEND cell unless it + is the right length. + + For this, we might add a second, longer onion-key to router + descriptors, and a second CREATE2 cell to open new circuits + using this key type. It should contain not only the onionskin, but + also information on onionskin version and ciphersuite. Onionskins + generated for CREATE2 cells should use a larger DH group as well, and + keys should be derived from DH results using a better digest algorithm. + + We should remove the length limit on EXTEND cells, backported to all + supported stable versions; call these "EXTEND2" cells. Call these + "lightly patched". Clients could use the new EXTEND2/CREATE2 format + whenever using a lightly patched or new server to extend to a new + server, and the old EXTEND/CREATE format otherwise. + + The new onion skin format should try to avoid the design oddities of + our old one. Instead of its current iffy hybrid encryption scheme, it + should probably do something more like a BEAR/LIONESS operation with a + fixed key on the g^x value, followed by a public key encryption on the + start of the encrypted data. (Robert reminded me about this + construction.) + + The current EXTEND cell format ends with a router identity + fingerprint, which is used by the extended-from router to authenticate + the extended-to router when it connects. Changes to this will + interact with changes to how long an identity key can be and to the + link protocol; see notes on the link protocol above and about router + identity below. + +3.2.1. Circuit-extend crypto: fast case + + When we do unauthenticated circuit extends with CREATE/CREATED_FAST, + the two input values are combined with SHA1. I believe that's okay; + using any entropy here at all is overkill. + +3.3. Relay crypto + + Upon receiving relay cells, a router transform the payload portion of + the cell with the appropriate key appropriate key, sees if it + recognized the cell (the recognized field is zero, the digest field is + correct, the cell is outbound), and pass them on if not. It is + possible for each hop in the circuit to handle the relay crypto + differently; nobody but the client and the hop in question need to + coordinate their operations. + + It's not clear, though, whether updating the relay crypto algorithms + would help anything, unless we changed the whole relay cell processing + format too. The stream cipher is good enough, and the use of 4 bytes + of digest does not have enough bits to provide cryptographic strength, + no matter what cipher we use. + + This is the likeliest area for the second-system effect to strike; + there are lots of opportunities to try to be more clever than we are + now. + +3.4. Router identity + + This is one of the hardest things to change. Right now, routers are + identified by a "fingerprint" equal to the SHA1 hash of their 1024-bit + identity key as given in their router descriptor. No existing Tor + will accept any other size of identity key, or any other hash + algorithm. The identity key itself is used: + - To sign the router descriptors + - To sign link-key certificates + + The fingerprint is used: + - To identify a router identity key in EXTEND cells + - To identify a router identity key in bridge lines + - Throughout the controller interface + - To fetch bridge descriptors for a bridge + - To identify a particular router throughout the codebase + - In the .exit notation. + - By the controller to identify nodes + - To identify servers in the logs + - Probably other places too + + To begin to allow other key types, key-lengths, and hash functions, we + would either need to wait till all current Tors are obsolete, or allow + routers to have more than one identity for a while. + + To allow routers to have more than one identity, we need to + cross-certify identity keys. We can do this trivially, in theory, by + listing both keys in the router descriptor and having both identities + sign the descriptor. In practice, we will need to analyze this pretty + carefully to avoid attacks where one key is completely fake aimed to + trick old clients somehow. + + Upgrading the hash algorithm once would be easy: just say that all + new-type keys get hashed using the new hash algorithm. Remaining + future-proof could be tricky. + + This is one of the hardest areas to update; "SHA1 of identity key" is + assumed in so many places throughout Tor that we'll probably need a + lot of design work to work with something else. + +3.5. Directory objects + + Fortunately, the problem is not so bad for consensuses themselves, + because: + - Authority identity keys are allowed to be RSA keys of any length; + in practice I think they are all 3072 bits. + - Authority signing keys are also allowed to be of any length. + AFAIK the code works with longer signing keys just fine. + - Currently, votes are hashed with both sha1 and sha256; adding + more hash algorithms isn't so hard. + - Microdescriptor consensuses are all signed using sha256. While + regular consensuses are signed using sha1, exploitable collisions + are hard to come up with, since once you had a collision, you + would need to get a majority of other authorities to agree to + generate it. + + Router descriptors are currently identified by SHA1 digests of their + identity keys and descriptor digests in regular consensuses, and by + SHA1 digests of identity keys and SHA256 digests of microdescriptors + in microdesc consensuses. The consensus-flavors design allows us to + generate new flavors of consensus that identity routers by new hashes + of their identity keys. Alternatively, existing consensuses could be + expanded to contain more hashes, though that would have some space + concerns. + + Router descriptors themselves are signed using RSA-1024 identity keys + and SHA1. For information on updating identity keys, see above. + + Router descriptors and extra-info documents cross-certify one another + using SHA1. + + Mirodescriptors are currently specified to contain exactly one + onion key, of length 1024 bits. + +3.6. The directory protocol + + Most objects are indexed by SHA1 hash of an identity key or a + descriptor object. Adding more hash types wouldn't be a huge problem + at the directory cache level. + +3.7. The hidden service protocol + + Hidden services self-identify by a 1024-bit RSA key. Other keys + lengths are not supported. This key is turned into an 80 bit half + SHA-1 hash for hidden service names. + + The most simple change here would be to set an interface for putting + the whole ugly SHA1 hash in the hidden service name. Remember that + this needs to coexist with the authentication system which also uses + .onion hostnames; that hostnames top out around 255 characters and and + their components top out at 63. + + Currently, ESTABLISH_INTRO cells take a key length parameter, so in + theory they allow longer keys. The rest of the protocol assumes that + this will be hashed into a 20-byte SHA1 identifier. Changing that + would require changes at the introduction point as well as the hidden + service. + + The parsing code for hidden service descriptors currently enforce a + 1024-byte identity key, though this does not seem to be described in + the specification. Changing that would be at least as hard as doing + it for regular identity keys. + + Fortunately, hidden services are nearly completely orthogonal to + everything else. + From 021e4ac07eee9db9e535f3e5671a76e768f6042f Mon Sep 17 00:00:00 2001 From: Robert Ransom Date: Mon, 13 Dec 2010 22:34:10 -0800 Subject: [PATCH 4/7] Fix typos. --- .../proposals/ideas/xxx-crypto-migration.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/spec/proposals/ideas/xxx-crypto-migration.txt b/doc/spec/proposals/ideas/xxx-crypto-migration.txt index baebfb527d..edbc7a23cb 100644 --- a/doc/spec/proposals/ideas/xxx-crypto-migration.txt +++ b/doc/spec/proposals/ideas/xxx-crypto-migration.txt @@ -176,7 +176,7 @@ Created: 12 December 2010 - anything we would have to implement from scratch - anything without a nice BSD-licensed C implementation - Some times we'll have the choice of a more efficient algorithm or a + Sometimes we'll have the choice of a more efficient algorithm or a more boring & well-analyzed one. We should not even consider trading conservative design for efficiency unless we are firmly in the critical path. @@ -211,7 +211,7 @@ Created: 12 December 2010 really improves matters or not. Recall also that for anti-fingerprinting reasons, we're thinking of - revising the protocol handshake some time in the 0.2.3.x timeframe. + revising the protocol handshake sometime in the 0.2.3.x timeframe. If we do that, that might be a good time to make sure that we aren't limited by the old identity key size. @@ -256,10 +256,10 @@ Created: 12 December 2010 3.3. Relay crypto - Upon receiving relay cells, a router transform the payload portion of + Upon receiving relay cells, a router transforms the payload portion of the cell with the appropriate key appropriate key, sees if it - recognized the cell (the recognized field is zero, the digest field is - correct, the cell is outbound), and pass them on if not. It is + recognizes the cell (the recognized field is zero, the digest field is + correct, the cell is outbound), and passes them on if not. It is possible for each hop in the circuit to handle the relay crypto differently; nobody but the client and the hop in question need to coordinate their operations. @@ -295,7 +295,7 @@ Created: 12 December 2010 - To identify servers in the logs - Probably other places too - To begin to allow other key types, key-lengths, and hash functions, we + To begin to allow other key types, key lengths, and hash functions, we would either need to wait till all current Tors are obsolete, or allow routers to have more than one identity for a while. @@ -345,7 +345,7 @@ Created: 12 December 2010 Router descriptors and extra-info documents cross-certify one another using SHA1. - Mirodescriptors are currently specified to contain exactly one + Microdescriptors are currently specified to contain exactly one onion key, of length 1024 bits. 3.6. The directory protocol @@ -356,7 +356,7 @@ Created: 12 December 2010 3.7. The hidden service protocol - Hidden services self-identify by a 1024-bit RSA key. Other keys + Hidden services self-identify by a 1024-bit RSA key. Other key lengths are not supported. This key is turned into an 80 bit half SHA-1 hash for hidden service names. @@ -373,7 +373,7 @@ Created: 12 December 2010 service. The parsing code for hidden service descriptors currently enforce a - 1024-byte identity key, though this does not seem to be described in + 1024-bit identity key, though this does not seem to be described in the specification. Changing that would be at least as hard as doing it for regular identity keys. From 9776ba7fa44af429cff984d183e387cf00476a8f Mon Sep 17 00:00:00 2001 From: Robert Ransom Date: Mon, 13 Dec 2010 22:42:11 -0800 Subject: [PATCH 5/7] List another place router identity keys are used. --- doc/spec/proposals/ideas/xxx-crypto-migration.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/spec/proposals/ideas/xxx-crypto-migration.txt b/doc/spec/proposals/ideas/xxx-crypto-migration.txt index edbc7a23cb..1c734229b8 100644 --- a/doc/spec/proposals/ideas/xxx-crypto-migration.txt +++ b/doc/spec/proposals/ideas/xxx-crypto-migration.txt @@ -283,6 +283,8 @@ Created: 12 December 2010 algorithm. The identity key itself is used: - To sign the router descriptors - To sign link-key certificates + - To determine the least significant bits of circuit IDs used on a + Tor instance's links (see tor-spec §5.1) The fingerprint is used: - To identify a router identity key in EXTEND cells From 1361376e147e1ab11c182b8a2b0a0b96dd6da81b Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 14 Dec 2010 23:22:21 -0500 Subject: [PATCH 6/7] Add start of rransom's notes on tor crypto requirements --- .../ideas/xxx-crypto-requirements.txt | 83 +++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 doc/spec/proposals/ideas/xxx-crypto-requirements.txt diff --git a/doc/spec/proposals/ideas/xxx-crypto-requirements.txt b/doc/spec/proposals/ideas/xxx-crypto-requirements.txt new file mode 100644 index 0000000000..6e03523db7 --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-crypto-requirements.txt @@ -0,0 +1,83 @@ + +This draft is intended to specify the meaning of ‘secure’ for a Tor +circuit protocol, hopefully in enough detail that +mathematically-inclined cryptographers can use this definition to +prove that a Tor circuit protocol (or component thereof) is secure +under reasonably well-accepted assumptions. + +Tor's current circuit protocol consists of the CREATE, CREATED, RELAY, +DESTROY, CREATE_FAST, CREATED_FAST, and RELAY_EARLY cells (including +all subtypes of RELAY and RELAY_EARLY cells). Tor currently has two +circuit-extension handshake protocols: one consists of the CREATE and +CREATED cells; the other, used only over the TLS connection to the +first node in a circuit, consists of the CREATE_FAST and CREATED_FAST +cells. + + + +1. Every circuit-extension handshake protocol must provide forward +secrecy -- the protocol must allow both the client and the relay to +destroy, immediately after a circuit is closed, enough key material +that no attacker who can eavesdrop on all handshake and circuit cells +and who can seize and inspect the client and relay after the circuit +is closed will be able to decrypt any non-handshake data sent along +the circuit. + +In particular, the protocol must not require that a key which can be +used to decrypt non-handshake data be stored for a predetermined +period of time, as such a key must be written to persistent storage. + + + +2. Every circuit-extension handshake protocol must specify what key +material must be used only once in order to allow unlinkability of +circuit-extension handshakes. + + + +3. Every circuit-extension handshake protocol must authenticate the relay +to the client -- an attacker who can eavesdrop on all handshake and +circuit cells and who can participate in handshakes with the client +must not be able to determine a symmetric session key that a circuit +will use without either knowing a secret key corresponding to a +handshake-authentication public key published by the relay or breaking +a cryptosystem for which the relay published a +handshake-authentication public key. + + + +4. Every circuit-extension handshake protocol must ensure that neither +the client nor the relay can cause the handshake to result in a +predetermined symmetric session key. + + + +5. Every circuit-extension handshake protocol should ensure that an +attacker who can predict the relay's ephemeral secret input to the +handshake and can eavesdrop on all handshake and circuit cells, but +does not know a secret key corresponding to the +handshake-authentication public key used in the handshake, cannot +break the handshake-authentication public key's cryptosystem, and +cannot predict the client's ephemeral secret input to the handshake, +cannot predict the symmetric session keys used for the resulting +circuit. + + + +6. The circuit protocol must specify an end-to-end flow-control +mechanism, and must allow for the addition of new mechanisms. + + + +7. The circuit protocol should specify the statistics to be exchanged +between circuit endpoints in order to support end-to-end flow control, +and should specify how such statistics can be verified. + + + +8. The circuit protocol should allow an endpoint to verify that the other +endpoint is participating in an end-to-end flow-control protocol +honestly. + + + From d051751d718e0f8dbd73e6b9bcdacdd27e43bed2 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 14 Dec 2010 23:31:42 -0500 Subject: [PATCH 7/7] Reformat circuit crypto requirements as a proposal-like document --- .../ideas/xxx-crypto-requirements.txt | 147 ++++++++---------- 1 file changed, 68 insertions(+), 79 deletions(-) diff --git a/doc/spec/proposals/ideas/xxx-crypto-requirements.txt b/doc/spec/proposals/ideas/xxx-crypto-requirements.txt index 6e03523db7..8a8943a42f 100644 --- a/doc/spec/proposals/ideas/xxx-crypto-requirements.txt +++ b/doc/spec/proposals/ideas/xxx-crypto-requirements.txt @@ -1,83 +1,72 @@ +Title: Requirements for Tor's circuit cryptography +Author: Robert Ransom +Created: 12 December 2010 -This draft is intended to specify the meaning of ‘secure’ for a Tor -circuit protocol, hopefully in enough detail that -mathematically-inclined cryptographers can use this definition to -prove that a Tor circuit protocol (or component thereof) is secure -under reasonably well-accepted assumptions. - -Tor's current circuit protocol consists of the CREATE, CREATED, RELAY, -DESTROY, CREATE_FAST, CREATED_FAST, and RELAY_EARLY cells (including -all subtypes of RELAY and RELAY_EARLY cells). Tor currently has two -circuit-extension handshake protocols: one consists of the CREATE and -CREATED cells; the other, used only over the TLS connection to the -first node in a circuit, consists of the CREATE_FAST and CREATED_FAST -cells. - - - -1. Every circuit-extension handshake protocol must provide forward -secrecy -- the protocol must allow both the client and the relay to -destroy, immediately after a circuit is closed, enough key material -that no attacker who can eavesdrop on all handshake and circuit cells -and who can seize and inspect the client and relay after the circuit -is closed will be able to decrypt any non-handshake data sent along -the circuit. - -In particular, the protocol must not require that a key which can be -used to decrypt non-handshake data be stored for a predetermined -period of time, as such a key must be written to persistent storage. - - - -2. Every circuit-extension handshake protocol must specify what key -material must be used only once in order to allow unlinkability of -circuit-extension handshakes. - - - -3. Every circuit-extension handshake protocol must authenticate the relay -to the client -- an attacker who can eavesdrop on all handshake and -circuit cells and who can participate in handshakes with the client -must not be able to determine a symmetric session key that a circuit -will use without either knowing a secret key corresponding to a -handshake-authentication public key published by the relay or breaking -a cryptosystem for which the relay published a -handshake-authentication public key. - - - -4. Every circuit-extension handshake protocol must ensure that neither -the client nor the relay can cause the handshake to result in a -predetermined symmetric session key. - - - -5. Every circuit-extension handshake protocol should ensure that an -attacker who can predict the relay's ephemeral secret input to the -handshake and can eavesdrop on all handshake and circuit cells, but -does not know a secret key corresponding to the -handshake-authentication public key used in the handshake, cannot -break the handshake-authentication public key's cryptosystem, and -cannot predict the client's ephemeral secret input to the handshake, -cannot predict the symmetric session keys used for the resulting -circuit. - - - -6. The circuit protocol must specify an end-to-end flow-control -mechanism, and must allow for the addition of new mechanisms. - - - -7. The circuit protocol should specify the statistics to be exchanged -between circuit endpoints in order to support end-to-end flow control, -and should specify how such statistics can be verified. - - - -8. The circuit protocol should allow an endpoint to verify that the other -endpoint is participating in an end-to-end flow-control protocol -honestly. +Overview + This draft is intended to specify the meaning of 'secure' for a Tor + circuit protocol, hopefully in enough detail that + mathematically-inclined cryptographers can use this definition to + prove that a Tor circuit protocol (or component thereof) is secure + under reasonably well-accepted assumptions. + + Tor's current circuit protocol consists of the CREATE, CREATED, RELAY, + DESTROY, CREATE_FAST, CREATED_FAST, and RELAY_EARLY cells (including + all subtypes of RELAY and RELAY_EARLY cells). Tor currently has two + circuit-extension handshake protocols: one consists of the CREATE and + CREATED cells; the other, used only over the TLS connection to the + first node in a circuit, consists of the CREATE_FAST and CREATED_FAST + cells. + +Requirements + + 1. Every circuit-extension handshake protocol must provide forward + secrecy -- the protocol must allow both the client and the relay to + destroy, immediately after a circuit is closed, enough key material + that no attacker who can eavesdrop on all handshake and circuit cells + and who can seize and inspect the client and relay after the circuit + is closed will be able to decrypt any non-handshake data sent along + the circuit. + + In particular, the protocol must not require that a key which can be + used to decrypt non-handshake data be stored for a predetermined + period of time, as such a key must be written to persistent storage. + + 2. Every circuit-extension handshake protocol must specify what key + material must be used only once in order to allow unlinkability of + circuit-extension handshakes. + + 3. Every circuit-extension handshake protocol must authenticate the relay + to the client -- an attacker who can eavesdrop on all handshake and + circuit cells and who can participate in handshakes with the client + must not be able to determine a symmetric session key that a circuit + will use without either knowing a secret key corresponding to a + handshake-authentication public key published by the relay or breaking + a cryptosystem for which the relay published a + handshake-authentication public key. + + 4. Every circuit-extension handshake protocol must ensure that neither + the client nor the relay can cause the handshake to result in a + predetermined symmetric session key. + + 5. Every circuit-extension handshake protocol should ensure that an + attacker who can predict the relay's ephemeral secret input to the + handshake and can eavesdrop on all handshake and circuit cells, but + does not know a secret key corresponding to the + handshake-authentication public key used in the handshake, cannot + break the handshake-authentication public key's cryptosystem, and + cannot predict the client's ephemeral secret input to the handshake, + cannot predict the symmetric session keys used for the resulting + circuit. + + 6. The circuit protocol must specify an end-to-end flow-control + mechanism, and must allow for the addition of new mechanisms. + + 7. The circuit protocol should specify the statistics to be exchanged + between circuit endpoints in order to support end-to-end flow control, + and should specify how such statistics can be verified. + 8. The circuit protocol should allow an endpoint to verify that the other + endpoint is participating in an end-to-end flow-control protocol + honestly.