[tor-dev] RFC: obfs4 (Name not final)

[Philipp Winter]

On Wed, May 21, 2014 at 06:36:52AM +0000, Yawning Angel wrote:
>  * obfs4 always does a full handshake.  ScrambleSuit style session
>    ticket handshakes are not supported.  Even with Elligator2 mapping
>    taken into account, the obfs4 handshake is significantly faster, so
>    there is less of a need for this.

That's probably a good idea as it leads to less code and complexity.  We added
session tickets when we were experimenting with a proof-of-work scheme instead
of the shared secret which is now wrapped around UniformDH.  The PoW scheme
turned out to be unpractical but we kept session tickets as they still provided
a small computational benefit.

>  * Should obfs4proxy also have (disabled) IAT obfuscation?  Adding it
>    later will not require wire protocol changes.

I don't think that inter-arrival times are a significant practical threat at
this point.  In addition, it has a major impact on throughput which is the
reason why obfsproxy's ScrambleSuit ships with the option being disabled.  As
you write, it shouldn't be a problem to add IAT obfuscation later on if it
turns out to be important for some reason.

>  * The handshake length mimics ScrambleSuit in terms of maximum
>    padding (< 1500 bytes).  Should this be increased to be similar to
>    obfs3 (~8k of maximum padding)?  The server side cost for this
>    shouldn't be that high.

I'm not sure if sound decisions can be made without comprehensive data showing
how real-world protocols behave.  ScrambleSuit's (and perhaps also obfs3's)
padding length was determined by gut feeling, so ~8k might be fine as well.

>  * Is this different enough from ScrambleSuit to be worth deploying?  I
>    would be ok with this ending up as "just a research project" and
>    shelving it if the consensus is otherwise.

While you're at it, there are some other things which might be worth improving:

- ScrambleSuit's framing mechanism is vulnerable to this attack:
  <http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf>
  In a nutshell, the receiver needs to decrypt the ScrambleSuit header before
  it is able to verify the HMAC which makes it possible for an attacker to
  tamper with the length fields.  While there are probably simpler attacks, it
  would be nice to have a fix for this problem.

- We didn't push the idea of polymorphism very far.  There are more flow
  characteristics such as "packet directions", "total bytes sent", or "total
  bytes received" which could be disguised in a systematic fashion.  While
  reasonable protection against traffic analysis is tricky, we could at least
  decrease a classifier's accuracy a bit more.  Some ideas could be taken from
  this paper: <http://arxiv.org/pdf/1401.6022v1.pdf>

Cheers,
Philipp