Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#29206: New design for client -- server protocol for Snowflake
-----------------------------------------------+---------------------------
 Reporter:  cohosh                             |          Owner:  cohosh
     Type:  task                               |         Status:
                                               |  needs_review
 Priority:  Medium                             |      Milestone:
Component:  Circumvention/Snowflake            |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  anti-censorship-roadmap-september  |  Actual Points:
Parent ID:                                     |         Points:  6
 Reviewer:  dcf                                |        Sponsor:
                                               |  Sponsor28-must
-----------------------------------------------+---------------------------

Comment (by dcf):

 Replying to [comment:33 cohosh]:
 > Alright, I had a chance to take a look at the obfs4 integration with
 Turbo Tunnel:
 https://github.com/net4people/bbs/issues/14#issuecomment-544747519
 >
 > Another option is to just scrap the work done here so far and work turbo
 tunnel into snowflake.

 We talked about this at [http://meetbot.debian.net/tor-meeting/2019/tor-
 meeting.2019-10-24-16.59.html the last meeting] and decided to continue
 with snowflakeConn, because work on adapting Snowflake to a turbo tunnel
 scheme is at least a few months off.

 > I'm curious about whether Turbo Tunnel is going to be implemented as a
 separate library.

 No, I'm not planning anything like that. For one thing, turbo tunnel isn't
 a singular thing, it's more of a high-level design principle: putting a
 session/reliability layer in the middle of a circumvention protocol
 enables a lot of nice features. Even the connection migration stuff shown
 off in the obfs4proxy demo, I wouldn't call core to the turbo tunnel idea;
 it's just one of many things made possible. My second consideration is
 that I feel we're still in the phase of requirements gathering, which is
 accomplished by doing a series of non-reusable, concrete implementations.
 The likelihood of getting the API wrong is too high otherwise. With my
 software engineer hat on, I see a resusable library at this point as
 having both high risk and high cost.

 I am, however, planning to try implementing the turbo tunnel idea directly
 in Snowflake, as part of this whole process.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29206#comment:35>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs