[tor-dev] Scheduling future Tor proposal reading groups

[teor]

> On 30 Nov. 2016, at 05:04, George Kadianakis <desnacked at riseup.net> wrote:
> 
> Hello people,
> 
> in the beginning of 2016 we started organizing little-t-tor proposal
> reading groups in IRC, where we would discuss the current status of Tor
> proposals and coordinate on how to move them forward. You can see a list
> of previous such meetings here:
>         https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/MeetingSchedule#Proposalreviewmeetings
> 
> Unfortunately at some point, 2016 started showing its true self, and we kind of
> stopped doing those meetings in March. But they were useful, and we should
> probably start doing them again!
> 
> I went through the mailing list and found a few interesting subjects that could
> benefit from group discussion. Here are some ideas:
> 
> - Post-Quantum key exchanges for Tor 
> 
>  There are a few proposals falling under this topic that were developed in the
>  past months. Here are a few:
>    https://gitweb.torproject.org/torspec.git/tree/proposals/263-ntru-for-pq-handshake.txt
>    https://gitweb.torproject.org/torspec.git/tree/proposals/269-hybrid-handshake.txt
>    https://gitweb.torproject.org/torspec.git/tree/proposals/270-newhope-hybrid-handshake.txt
>    https://lists.torproject.org/pipermail/tor-dev/2016-October/011553.html
> 
>  I'm far from an expert on this field, so I'm not sure about the current
>  status of this project and the right direction to approach it. However, it
>  seems that there have been enough developments here lately that a group
>  discussion might be useful.
> 
> - A name system API for Tor
> 
>  This is a proposal suggesting a single API that allows us to integrate secure
>  name systems with Tor hidden services:
>    https://lists.torproject.org/pipermail/tor-dev/2016-October/011514.html
> 
>  The proposal received useful feedback in and out of the mailing list. It
>  seems that implementing the proposal as part of a Tor controller might be an
>  easier way to test it. Some discussion on future directions might be helpful
>  here, as this is something that will be needed sooner than later.
> 
> - New topics in Next Gen Hidden Services
> 
>  We've done multiple IRC meetings on prop224, but it keeps on growing as it's
>  being developed. Here are a few topics that might be worth discussing as a group:
>  - Control port API for hidden services (https://trac.torproject.org/projects/tor/ticket/20699)
>  - torrc UX for hidden services (https://lists.torproject.org/pipermail/tor-dev/2016-November/011661.html)
>  - torrc/control UX for hidden service client auth (https://lists.torproject.org/pipermail/tor-dev/2016-November/011617.html)
>  - UX for offline keys (https://trac.torproject.org/projects/tor/ticket/18098)
>  - UX of hidden services on Tor Browser
> 
> - Prop271: Another algorithm for guard selection
> 
>  We've also done a few IRC meetings on future guard algorithms, but we are now
>  closer to completing that project than ever. After we have a few results and
>  statistics of the new guard algorithm, it might be worth scheduling a meeting
>  to discuss how well it works and ways to improve it.
> 
> - And here are some more misc projects that might be worth discussing further:
>  - The Tor browser sandbox that Yawning is developing and UX implications?

All of the above seem like a good idea.

>  - prop273: Exit relay pinning for web services ?

This got some negative feedback on the mailing list that I tend to agree with,
the proposal should either be shelved, or heavily modified to address the
client attacks it enables.

(I'm not sure it's possible to modify it to address the attacks.)

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------