[Whonix-devel] RFC 6528 revision for better system privacy

[Steven M. Bellovin]

On 12 Jan 2017, at 20:49, bancfc at openmailbox.org wrote:

> Hi Steven and Fernando,
>
> I am a Whonix (anonymity OS) dev and would like to discuss the RFC 
> 6528 [0] you worked on. There has been privacy research in the area of 
> timer and clock leaks in network protocols that can aid adversaries in 
> deanonymizing Tor clients and hidden services. There is a practical 
> attack where an adversary can skew timer measurements by overloading 
> target machines and affect the oscillation of timer crystals in 
> predictable patterns that can be remotely measured in TCP sequence 
> numbers.[1]
>
> Please consider revising the RFC to omit the requirement of xoring 
> timer output with TCP ISNs. Recently the Linux kernel gained the 
> SipHash PRF to generate better sequence numbers and deprecated MD5. 
> This further reduces the necessity of including timer input which has 
> become a side channel that aids traffic correlation and endangers 
> privacy focused use cases.

I'm a bit confused -- there's no requirement in 6528 for XORing a timer. 
  That plus sign in the equation at the start of Section 3 signifies 
addition (modulo 2^32, I should mention, since it's a 32-bit field), not 
exclusive-OR.  I'd have to think about it, but I'm not at all convinced 
that XOR would even work in that context.  The result of the actually 
specified operation is that the ISN of a given connection is uniformly 
randomly distributed in [0,2^32-1] and independent of the ISN of any 
other connection.

I'm still reading [2], but I don't see the relevance of the attack to 
Tor.  Tor does not provide end-to-end TCP; rather, it provides 
end-to-end transport of the TCP payload, correct?  In that case, the 
sequence numbers of the sender are only visible as far as its Tor 
entrance node, but they're useless for an attack -- anyone who observes 
those sequence numbers already has the source IP address; there's no 
added value, unless the threat is some machine whose source IP address 
is changing rapidly.  But if that's your threat model, you can look at 
the TCP PAWS timer.  Beyond that, though [2] notes that subtracting two 
ISN will give you the timer difference, that's only true if you subtract 
two ISNs for the same connection -- and that's very hard in this 
context.  The source port will change constantly, with each new TCP 
open, and while you can manage the same connection when calling a 
server, with a Tor hidden service the server is actually a client at the 
TCP level, so it picks its own port numbers.

I'm unfamiliar with what Linux has done to get away from RFC 1948/6528.  
Simply replacing MD5 with SipHash does not do away with the need for the 
timer.  The whole purpose of the timer is to preserve TCP connection 
integrity semantics; omitting it changes those semantics.  Preserving 
them was the whole point of 1948, or I'd have suggesting simply using a 
good PRNG for ISNs in my 1989 paper.  Do you have a pointer to any 
documentation describing what's done?

Anyway -- at the moment, I don't see an attack.  As best I can tell, [2] 
describes a way to leak data via the ISN without risk of detection (and 
I'm not even convinced that the threat of detection is real for a Tor 
hidden service, given the client port number issue).  That's not the 
same as being able to fingerprint a timer in a real Tor situation.  Even 
if it was, Tor does not relay TCP headers, so they're not visible past 
the first Tor hop.

Mind you, I'm not saying you're wrong.  I am saying that you haven't 
persuaded me that you're right or that your suggestion preserves TCP 
semantics for non-Tor situations.

> [0] https://tools.ietf.org/html/rfc6528
> [1] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf
> [2] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ih05coverttcp.pdf



         --Steve Bellovin, https://www.cs.columbia.edu/~smb