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

[Yawning Angel]

On Fri, 23 May 2014 14:16:49 +0200
Philipp Winter <phw at nymity.ch> wrote:

[snippity]
> >  * 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.

I went and added the code last night, so it's there if needed (as a
command line option).

> >  * 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.

On the gut feeling of "bigger handshakes = more random *waves hands*", I
went and jacked it up last night.  More real world data would be nice.

> >  * 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.

I believe obfs4 does not have the plaintext recovery issue as the length
field is separate from the AEAD construct (Though at present an
adversary tampering with the length field is only caught by MAC
errors).  However I will go and implement randomizing the length on a
out of bounds length value (as suggested in section 6 of the paper) to
reduce the timing differential.

From reading the paper, I do not believe that ScrambleSuit's
vulnerability leads to plaintext recovery either as it uses CTR-AES and
recovery is based off CBC-AES, though as the authors note, there may be
other side channel hazards.
 
> - 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>

This is the sort of thing that mjuarez is looking into as part of
GSOC.  As long as a padding frame type is defined, incorporating the
results of his research at a later date should be possible without
changes to the wire protocol.

Thanks for the feedback!

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140523/5fb22358/attachment.sig>