Re: [tor-dev] Open Proposals as of June 2012
On Mon, Jun 18, 2012 at 10:40 PM, ahmed ah...@linuxism.com wrote: On Mon, 2012-06-18 at 17:26 -0400, Nick Mathewson wrote: 194 Mnemonic .onion URLs Hello: I made a post about that topic in February, and it seems no one was interested. I can implement a dictionary compiler and address resolver. Should I work on it? Hi, Ahmed! It could be a good idea to write up a proposal here. But before you go too far on it, you should look at the other draft proposals in this area, including 194, and some others that were brought up in response when 194 was discussed on this mailing list. There's the thread starting at http://archives.seul.org/or/dev/Feb-2012/msg00048.html And the one at http://archives.seul.org/or/dev/Dec-2011/msg00021.html There's the design at http://archives.seul.org/or/dev/Dec-2011/msg00035.html And probably more too. yrs, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Open Proposals as of June 2012
On Mon, Jun 18, 2012 at 8:30 PM, Jacob Appelbaum ja...@appelbaum.net wrote: On 06/18/2012 11:26 PM, Nick Mathewson wrote: This list of open Tor proposals is based on one I sent out in May of last year. Since I'd like to do this more regularly, I have added to each description the date when I wrote it. Most of the summaries from older proposals are unchanged since last May; the later ones in the list for 6/2012 I wrote pretty quickly since I want to get out the door tonight for an appointment, but I want to send this list out without further delay. Perhaps this would make for a nice weekly cronjob? :) Say rather, a regular task for me to do around the middle of the month. I don't expect movement to be so fast that much changes each week OPEN, DRAFT, AND ACCEPTED PROPOSALS: 117 IPv6 exits IPv6 is still the future, but now it's the kind of future that's unevenly distributed. It's time to do this one so that IPv6 traffic can be sent over Tor. It needs updating to work properly with microdescriptors; it also has some open questions about DNS. (6/2012) I'm a little unclear on the issue of DNS with regard to v6. I feel like we're having lots of DNS blocking issues. What specifically is the issue? Is Linus hacking on this? Mostly concerning which address to connect to when a user says BEGIN www.example.com, and which to report to the user, under what circumstances. The proposal, though kind of old and funky, *does* explain this. [] psychoed? :-) Whee spellcheck. -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 202: Two improved relay encryption protocols for Tor cells
On Tue, Jun 19, 2012 at 2:06 PM, Robert Ransom rransom.8...@gmail.com wrote: On 6/19/12, Nick Mathewson ni...@freehaven.net wrote: Filename: 202-improved-relay-crypto.txt Any new approach should be able to coexist on a circuit with the old approach. That is, if Alice wants to build a circuit through Bob1, Bob2, and Bob3, and only Bob2 supports a revised relay protocol, then Alice should be able to build a circuit such that she can have Bob1 and Bob3 process each cell with the current protocol, and Bob2 process it with a revised protocol. (Why? Because if all nodes in a circuit needed to use the same relay protocol, then each node could learn information about the other nodes in the circuit from which relay protocol was chosen. For example, if Bob1 supports the new protocol, and sees that the old relay protocol is in use, and knows that Bob2 supports the new one, then Bob1 has learned that Bob3 is some node that does not support the new relay protocol.) This feature is unsafe to use. Each client must use the same circuit-extension protocol for every relay on every circuit it builds. Do you mean that every client must use at most one circuit-extension protocol on all circuits, or do you mean that every circuit must by built by at most one circuit-extension protocol? And why? And how would you have either*of those without having the choice of circuit extension protocol used at any hop in the circuit leak to the attacker which other nodes might be later in the circuit? (In other words, if I'm a guard, and I support an improved protocol, and I know the client supports it, and the middle node supports it, but the client does not use it, I can deduce that the exit node does not support the improved protocol.) yrs, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [GSoC] Tails Server
Hi, jvoisin wrote (19 Jun 2012 01:53:43 GMT) : I am sorry but I won't be able to pursue/achieve my GSoC[1] for personal reasons that I prefer not disclose on a public mailing list. Sorry about this. I hope things will be better for you soon. If we can help, please feel free to ask. I'd rather not pressure you now, but if you want to come back and work on Tails server with us at any later time, you are *much* welcome! Take care, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
