Not sure I understand "This is bad because it provides lots of entropy to fingerprint devices"; it is not clear to me what "it" refers to. Assuming it refers to jiffies, I hope that jiffies is not used to provide entropy to anything. If it does, maybe the code relying on it should be changed.
Note that the value is set when the socket is created. As such, it does not leak a current value of jiffies, but the value of jiffies when the socket was created. I am not sure if I would call that a leak. Also note that this is not a tcp specific problem - other IP protocols do the same, sometimes even using jiffies directly.

Anyway, I am neither a security nor a networking expert; this should be evaluated by those who are. At the same time, I am wary of changing tcp code unilaterally, much less changing a field like this. The case for this change should be made upstream.

This looks quite low entropy to me. Good luck exploiting this.

Real problem came with TCP TS option, which was clearly sending the 32bit jiffies on the wire.

This was fixed in linux-4.10

+mnissler@ for feedback from security folks.

Eric, thanks a lot for chiming in! I can see that the v4.12 kernel has 95a22caee396cef and 84b114b98452c43 -- does that mean that TCP timestamp fingerprinting is solved or are there remaining issues?

Concerning the exploitability of IPID^ISN: Assuming HZ=1000 (as is the case for Chromebooks) and attacker time resolution of 100ms (rather conservative) this means an attacker can distinguish 2**16/100=655 different states (~9 bits of entropy). The birthday bound of that is sqrt(pi/2*655)=32 which means that approximately 32 devices could be distinguished behind a NAT via IPID^ISN which likely in many cases is sufficient (together with the public IP address) to uniquely identify a device. Thus imho there would be significant merit in removing the jiffies contribution to the IP ID.

v4.12 kernel being release after v4.10, it includes the fix on TCP TS randomization. (ie 32bit jiffies is no longer leaked)

Honestly I do not understand what you are referring to about distinguishing devices behind a NAT.
A NAT is not something that adds security.

If you have a known attack using 16bit of jiffies, please let us know, and make sure hundred of call sites in the kernel no longer uses jiffies.

It's a fingerprinting issue: A passive observer on the network may learn how many devices operate behind a NAT and may group the observed network traffic by device. If a part of the grouped traffic can be associated with a person, the remainder of the traffic of that group may be associated with that same person, breaking plausible deniability ("somebody else on that wifi did it") for that person. In general we would like the network stack to reveal as little information about the identity of the user/device as possible, including correlations between traffic from the same device.

But the presence of the NAT has nothing to do with IP ID generation of a particular host behind the NAT.

To my knowledge no firewall ever tried to rewrite IP ID.
Are they broken as well, considering most linux kernels are leaking 16 bits of jiffies ?

Thiemo to follow up on the question in #9.

Re comment #9: This has nothing to do with NAT mangling the traffic. In fact it's a problem even without NAT. The offset of jiffies w.r.t. wall clock provides a certain amount entropy (up to 16 bits in this case, depending on measurement precision) that may be used to re-identify the device after it has changed IP address.