Designing and implementing improved circuit-setup protocol [was: GSoC 2011]
Quoting the whole message in my reply, since we're moving this to tor-dev where it belongs. On Wed, Mar 23, 2011 at 1:36 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
On Wed, 23 Mar 2011 12:54:17 -0400 Nick Mathewson <nickm@freehaven.net> wrote:
On Wed, Mar 23, 2011 at 8:10 AM, George Kadianakis <desnacked@gmail.com> wrote:
Hey Robert and Nick,
I hate bureaucratic procedures and yet I have to send my GSoC application 'till the 8th of April; so I want to get done with it.
My application should have "a project proposal, why you'd like to execute on this particular project, and the reason you're the best individual to do so." (that was taken from GSoC FAQ).
So regarding the project proposal, I talked with Robert yesterday and he told me: 02:18:24 <rransom> asn: Implementing the new circuit protocol will be a good GSoC project for you. I think identity key migration (and thus link protocol migration) will require too much beyond the new circuit protocol. I suppose that by "new circuit protocol" you mean the section 3.2 of xxx-crypto-migration.txt, Robert.
How do you feel about this, Nick?
It could be helpful. I don't have a good sense of how much work this would be, since I don't have a good sense of what the new protocol would actually be. Robert -- how would you think this would break down into a summer's worth of work?
The first step in the Great Tor Crypto Migration is to add new CREATE2 and EXTEND2 RELAY cell types. They can be used with the existing circuit-extension handshake and link protocol initially, but will be extensible to support new ones.
Further steps, all independent of each other:
* Add 128-byte and 2048-byte RELAY cells and a circuit-configuration cell, initially to allow the client to change the cell size to be used on a circuit.
* Refactor Tor's cryptographic primitive abstractions to accommodate public-key encryption primitives, public-key signature primitives, symmetric authenticated encryption, symmetric block encryption, and hashes.
* Implement one or more new link protocols that do not constrain a relay's choice of identity key cryptosystem.
Further mutually independent steps building on those above:
* Modify the directory protocol and implementation to support relays with multiple identity keys.
* Implement a new circuit-extension handshake (the part that involves ‘onionskins’).
* Implement a new circuit ciphersuite (the part that mangles cell data so that relay A can't see what data relay C sees).
Hm. These steps all stretch pretty far beyond what's just described in 3.2 of xxx-crypto-migration. I think they're probably more than we can promise to design before summer, and possibly more than a typical gsoc scope all put together.
I'm also a little concerned about the interaction of 3.2 and 3.3 ("Relay crypto") : I'll be surprised if it turns out that we can design a good circuit extend protocol without thinking about the countours of a new relay protocol. (Not that you'd have to build both at once, but we should think about them all as we design.)
It's actually the other way around -- we need a new EXTEND cell before we can use a new link protocol. (Otherwise, we would have to build in a covert channel (i.e. a backdoor for people who want to block Tor by handshake) in the new link protocol to indicate client and server link protocol versions, and that really *really* sucks.)
I'm talking about the stuff in 3.3: the relay protocol, where we process cells. Link protocol stuff is 3.1. Also, I'm talking about *design order*, not *implementation order*: The different parts of the Tor protocol are not sufficiently orthogonal that we can do them independently. Thus, we need to get most of the design changes sketched out before we can be reasonably say that any part of the redesign does what the other parts need.
Maybe we should get a protocol sketch together this week if the app is due April 8.
Yes. I have the EXTEND2 cell draft written; I bogged down on writing explanatory text (I thought I didn't have enough in the draft, but didn't know what to add).
Either way, I think this might be drifting into design work, so if there are no objections, I'd suggest that we follow up on the tor-dev mailing list. :)
Good idea.
Robert Ransom
Nick Mathewson <nickm@freehaven.net> writes:
<SNIP: asn: Tidying up the thread a bit> On Wed, Mar 23, 2011 at 1:36 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
The first step in the Great Tor Crypto Migration is to add new CREATE2 and EXTEND2 RELAY cell types. They can be used with the existing circuit-extension handshake and link protocol initially, but will be extensible to support new ones.
Further steps, all independent of each other:
* Add 128-byte and 2048-byte RELAY cells and a circuit-configuration cell, initially to allow the client to change the cell size to be used on a circuit.
* Refactor Tor's cryptographic primitive abstractions to accommodate public-key encryption primitives, public-key signature primitives, symmetric authenticated encryption, symmetric block encryption, and hashes.
* Implement one or more new link protocols that do not constrain a relay's choice of identity key cryptosystem.
Further mutually independent steps building on those above:
* Modify the directory protocol and implementation to support relays with multiple identity keys.
* Implement a new circuit-extension handshake (the part that involves ‘onionskins’).
* Implement a new circuit ciphersuite (the part that mangles cell data so that relay A can't see what data relay C sees).
Hm. These steps all stretch pretty far beyond what's just described in 3.2 of xxx-crypto-migration. I think they're probably more than we can promise to design before summer, and possibly more than a typical gsoc scope all put together.
This part:
* Implement a new circuit-extension handshake (the part that involves ‘onionskins’). is in the xxx-crypto-migration, and it might be worthwhile to tackle during GSoC. I'm not sure about the BEAR/LIONESS operation (are you?), but if we are to design the new CREATE2 cells and we indeed don't like the current way of passing DH paramaters around, maybe we should find another protocol to do it.
Of course, Robert's other ideas are holy and everything, but I think we should keep our goals humble so that we can produce an algorithmic implementation plan which will allow us to try to predict an implementation timeframe and see how many ideas we can fit into this GSoC project. For example, things that definitely must be done are: - Implement CREATE2 cells aiming to: * Upgrade onion keys. * Upgrade DH group * Upgrade hash function. - Implement EXTEND2 cells aiming to: * Remove length limit, so as to be able to carry the new onion-skins and identity key fingerprints. Of course all these, while having in mind the upgradability of our design (ie. being versatile wrt the identity key) Then we can move on to: - Design a new onion-skin protocol. - Play with some of Robert's ideas above. - Touch the relay protocol. 'till the GSoC bell rings. What are your priorities on this project?
I'm also a little concerned about the interaction of 3.2 and 3.3 ("Relay crypto") : I'll be surprised if it turns out that we can design a good circuit extend protocol without thinking about the countours of a new relay protocol. (Not that you'd have to build both at once, but we should think about them all as we design.)
It's actually the other way around -- we need a new EXTEND cell before we can use a new link protocol. (Otherwise, we would have to build in a covert channel (i.e. a backdoor for people who want to block Tor by handshake) in the new link protocol to indicate client and server link protocol versions, and that really *really* sucks.)
I'm talking about the stuff in 3.3: the relay protocol, where we process cells. Link protocol stuff is 3.1.
Also, I'm talking about *design order*, not *implementation order*: The different parts of the Tor protocol are not sufficiently orthogonal that we can do them independently. Thus, we need to get most of the design changes sketched out before we can be reasonably say that any part of the redesign does what the other parts need.
Maybe we should get a protocol sketch together this week if the app is due April 8.
Yes. I have the EXTEND2 cell draft written; I bogged down on writing explanatory text (I thought I didn't have enough in the draft, but didn't know what to add).
Sharing is caring!
Either way, I think this might be drifting into design work, so if there are no objections, I'd suggest that we follow up on the tor-dev mailing list. :)
Good idea.
Robert Ransom
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, 24 Mar 2011 01:28:42 +0100 George Kadianakis <desnacked@gmail.com> wrote:
Nick Mathewson <nickm@freehaven.net> writes:
<SNIP: asn: Tidying up the thread a bit> On Wed, Mar 23, 2011 at 1:36 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
The first step in the Great Tor Crypto Migration is to add new CREATE2 and EXTEND2 RELAY cell types. They can be used with the existing circuit-extension handshake and link protocol initially, but will be extensible to support new ones.
Further steps, all independent of each other:
* Add 128-byte and 2048-byte RELAY cells and a circuit-configuration cell, initially to allow the client to change the cell size to be used on a circuit.
* Refactor Tor's cryptographic primitive abstractions to accommodate public-key encryption primitives, public-key signature primitives, symmetric authenticated encryption, symmetric block encryption, and hashes.
* Implement one or more new link protocols that do not constrain a relay's choice of identity key cryptosystem.
Further mutually independent steps building on those above:
* Modify the directory protocol and implementation to support relays with multiple identity keys.
* Implement a new circuit-extension handshake (the part that involves ‘onionskins’).
* Implement a new circuit ciphersuite (the part that mangles cell data so that relay A can't see what data relay C sees).
Hm. These steps all stretch pretty far beyond what's just described in 3.2 of xxx-crypto-migration. I think they're probably more than we can promise to design before summer, and possibly more than a typical gsoc scope all put together.
This part:
* Implement a new circuit-extension handshake (the part that involves ‘onionskins’). is in the xxx-crypto-migration, and it might be worthwhile to tackle during GSoC. I'm not sure about the BEAR/LIONESS operation (are you?), but if we are to design the new CREATE2 cells and we indeed don't like the current way of passing DH paramaters around, maybe we should find another protocol to do it.
Currently, we do not pass DH parameters around in the circuit-extension protocol, just DH public keys. If we could pass new DH parameters in that protocol, we wouldn't need new circuit-extension protocols quite yet (although a new one would be a Good Thing anyway for performance reasons).
Of course, Robert's other ideas are holy and everything, but I think we should keep our goals humble so that we can produce an algorithmic implementation plan which will allow us to try to predict an implementation timeframe and see how many ideas we can fit into this GSoC project.
The list I gave above was purely to indicate some of the dependencies between crypto migration tasks. I don't expect you to do all of them for GSoC this summer; that list was intended to explain why you would most likely not be able to migrate Tor to a new size or type of identity key this summer.
For example, things that definitely must be done are: - Implement CREATE2 cells aiming to: * Upgrade onion keys. * Upgrade DH group * Upgrade hash function. - Implement EXTEND2 cells aiming to: * Remove length limit, so as to be able to carry the new onion-skins and identity key fingerprints. Of course all these, while having in mind the upgradability of our design (ie. being versatile wrt the identity key)
The *entire point* of the EXTEND2 and CREATE2 cells must be to allow future extension to new circuit and link protocols. We *will* want to add new circuit and link protocols in the near future, and we shouldn't need to add a new EXTEND17 or CREATE42 cell (and spend a cell type number) for each new protocol.
Then we can move on to: - Design a new onion-skin protocol. - Play with some of Robert's ideas above. - Touch the relay protocol. 'till the GSoC bell rings.
What are your priorities on this project?
I'm also a little concerned about the interaction of 3.2 and 3.3 ("Relay crypto") : I'll be surprised if it turns out that we can design a good circuit extend protocol without thinking about the countours of a new relay protocol. (Not that you'd have to build both at once, but we should think about them all as we design.)
It's actually the other way around -- we need a new EXTEND cell before we can use a new link protocol. (Otherwise, we would have to build in a covert channel (i.e. a backdoor for people who want to block Tor by handshake) in the new link protocol to indicate client and server link protocol versions, and that really *really* sucks.)
I'm talking about the stuff in 3.3: the relay protocol, where we process cells. Link protocol stuff is 3.1.
Also, I'm talking about *design order*, not *implementation order*: The different parts of the Tor protocol are not sufficiently orthogonal that we can do them independently. Thus, we need to get most of the design changes sketched out before we can be reasonably say that any part of the redesign does what the other parts need.
Circuit-extension handshake protocols and link protocols can be designed independently of the rest of the protocol. Link protocols are reasonably independent of the stuff sent over the link, and the proposals/ideas/xxx-crypto-requirements.txt document should specify *all* of the requirements for a new circuit-extension handshake protocol to not break the rest of Tor's protocols. (We should still dig through and annotate tor-spec.txt and rend-spec.txt with exactly what properties each part requires of circuit handshake protocols, but I'm quite sure I got all of those properties into xxx-crypto-requirements.)
Maybe we should get a protocol sketch together this week if the app is due April 8.
Yes. I have the EXTEND2 cell draft written; I bogged down on writing explanatory text (I thought I didn't have enough in the draft, but didn't know what to add).
Sharing is caring!
See attached for a nearly-finished draft. Robert Ransom
participants (3)
-
George Kadianakis -
Nick Mathewson -
Robert Ransom