[anti-censorship-team] Backward-compatible Turbo Tunnel in Snowflake

[Roger Dingledine]

On Mon, Feb 03, 2020 at 09:22:16PM -0700, David Fifield wrote:
> > My plan is to
> > reserve a distinguished static token (64-bit value) and have the client
> > send that at the beginning of the stream, before its ClientID, to
> > indicate that it uses Turbo Tunnel features.
>[...]
> Here's a commit that restores compatibility with current Snowflake
> clients. It works the way I described: the client sends a magic token at
> the beginning, one that non???Turbo Tunnel clients will never send.
>[...]
> The addition of a magic token prefix very slightly constrains traffic
> shaping.

Hi David!

Awesome news about the turbotunnel integration. I've been pondering
the backward compatibility thing ever since your first mail. Here are
two hopefully useful thoughts. Let me know if they are misunderstanding
things in some way.

(A) An extra 8 bytes for every new or resumed flow, forever, is kind
of sad. But it doesn't have to be forever: in the future, once the old
Snowflakes that don't send that static token are long gone, we can stop
requiring the token. (That is, if clients send it, that's fine, we can
recognize and strip it. And if they don't send it, that's fine too.)

(B) Another approach to backward compatibility might be to leave the old
Snowflake bridge up, not knowing what a turbotunnel is, and to put up
a new one nearby or somewhere else that expects turbotunnel connections.
Then after a few releases of Tor Browser, we could shut down the old
one and move on.

Approach 'B' would have been best to suggest in between your first mail
and your second one. Oops. :) Better late than never maybe.

Thanks!
--Roger