On Thu, Jul 19, 2012 at 11:38:30PM -0400, Andrew Lewman wrote:
All of that said, I totally agree that for #1, we need to be sure Andrew and the funder both understand that we can't promise that we'll deploy any particular transport protocol -- the first step is research, and that means step two must stay flexible.
I expect the pushback to be along the lines of "this is a deployment goal, not a research goal". If http/dns is bad, then we should figure out some way to deploy two unique transports in the wild.
If they want deployment without research, they've got two options.
First, we take existing research designs and see what happens when we try to make them deployable. In this case, the existing research designs are Skypemorph and Stegotorus. In both of these cases the deliverable should be something like "either deploy it, or write up an explanation of why it's not deployable yet and make an R&D roadmap for how to fix that." As I understand it, both Skypemorph and Stegotorus have a significant chance of being in the "or write up an explanation" camp today.
Or second, we could demonstrate the modularity of obfsproxy by adding a base64 transport module to it that wraps obfs2 flows in base64 encoding (in case the entropy test is how they bust us), and an http transport module that prepends some generic http headers and maybe a "Cookie: " string before jumping into either obfs2 or base64. I'm not clear on whether these two transports would ultimately be much harder to block than obfs2, but maybe they would. And if pyptlib turns out the way we hope, these alternate transports are a page of code each. Which means we could then turn our attention to the messier questions of how to get enough bridges up that support the transport, how to advertise their addresses, etc.
Now that I've written the two options like this, it seems the clear right answer is "do option two and in our spare time get started on option one."
--Roger