Re: [tor-dev] Open Proposals as of June 2012

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

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? :)

> 
> 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?


> 
>    131  Help users to verify they are using Tor
> 
>      Here's a proposal for making a torcheck-like website more reliable.
>      If anybody wants to pick it up (especially somebody working on
>      torcheck) and see whether it should be reopened or rejected, that
>      would be a fine thing. (5/2011)
> 

I've been thinking about this one a lot and I think I've come to the
conclusion that it isn't a good idea. I think as we had the .exit and we
have .onion, I think we might just want to have yet another special url.
Perhaps one that returns a totally safe bit of in band data - say, a
small home page that will tell you the status of your Tor client. This
was something Robert Hogan implemented for his Tor browser-like browser
project, I think.

It seems like a bad idea to have so many people building circuits and
then loading the same website when we can do the job locally. From a UX
perspective, I think it is cleaner and from a latency perspective, I
think it would be nicer overall. I hacked up some small api on check.tpo
for Torbutton long ago, so Torbutton could hit a url over SSL and
determine that Torbutton was routed over Tor. There are half a dozen
issues with this and well, I think we're still using it...

For Tor Browser, I think we should be smarter - a static home page with
a small bit of dynamic html that queries that same very api would
probably be a better UX experience. To build that very simple api into
the SOCKS proxy itself or into some kind of IPC with Tor's control port
would be better still.

>    146  Add new flag to reflect long-term stability
> 
>      From time to time we get the idea of having clients ship with a
>      reasonably recent consensus (or a list of directory mirrors),
>      so instead of bootstrapping from one of the authorities, they
>      can bootstrap from a regular directory cache.  The problem here
>      is that by the time the client is run, most of the directory
>      mirrors will be down or will have changed their IP.  This
>      proposal tries to address that.
> 
>      It needs analysis based on behavior of actual routers on the
>      network to see whether it could work, and what parameters might
>      work.
> 
>      Nevertheless, we should really do something like this, so that
>      we can ship a list of initial directory mirrors with Tor
>      (possibly via the "fallback consensus" deisgn), so that new
>      bootstrapping Tor clients don't all hammer the directory
>      authorities. (6/2012)

I almost wonder if the guard flag is essentially the same set of
constraints? I think we should discuss this at the TorDev in Italy if
possible...

> 
> 
>    195  TLS certificate normalization for Tor 0.2.4.x
> 
>      Here's the followup to proposal 179, containing all the parts
>      of proposal 179 that didn't get built, and a couple of other
>      tricks besides to try to make Tor's default protocol less
>      detectable.  I'm pretty psychoed about the part where we let
>      relays drop in any any self-signed or CA-issued certificate
>      that they like. (6/2012)

psychoed? :-)

I think while not directly certificate related, the DHE and RSA key bit
size discussion is relevant here:
https://trac.torproject.org/projects/tor/ticket/6088

Thanks for sending this mail out! I wanted to reply to other parts but I
need to do a bit of homework first.

All the best,
Jake
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev