It looks like the key will be accessible via the proc filesystem. But it's anyone's guess how many distros will faithfully schedule a cron job to rotate the key.
EDIT: Looks like the key is chosen at kernel module "late init" time. I think this is before any init scripts have had the opportunity to add back any entropy persisted from previous boots. So the entropy in the kernel pool is minimal. It may be plausible for a remote attacker to guess the key for a bunch of servers.
Also, if the key is not rotated by cron, it provides a single-packet method for a remote attacker to observe that a server has been rebooted since he last checked. This will give a good indication of how often security patches have been applied.
Might be better to have the keys rotated after a certain number of TFO cookies are generated rather than on a time-based schedule. This will prevent attackers from trying to make a huge number of requests in a set period of time.
The TFO cookie is only generated once per client "source IP" and is good until the key is changed on the server. (Scare quotes because at the source IP may be spoofed).
For an attacker to learn a cookie that's valid for a given victim "source IP", he only needs to be passive observer somewhere along the route. Even if we believe that's very hard in most cases, if it's possible at all, he has the mother-of-all anonymous reflected DoS amplifiers. http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02#secti...
So, yeah, using a key that's rotated after a short amount of time -or- number of uses (whichever comes first) seems like a good idea.
It's very easy to do in NAT'ed environments and the Linux kernel doesn't implement the suggestion of the RFC draft to include timestamps too.
An attacker who doesn't want to do a MITM attack because that might be noticed can set up sessions to all kinds of servers outside the NAT which support TFO. Then all these TFO cookies are used in spoofed SYN packets with the source IP being set to the host behind the NAT that the attacker wants to flood. Easy enough.
That will be more difficult if you've got a cluster of servers in which each new connection request of a client can end up at any of these servers at any given time. So the keys would have to be rotated simultaneously for all servers in the cluster.
EDIT: Looks like the key is chosen at kernel module "late init" time. I think this is before any init scripts have had the opportunity to add back any entropy persisted from previous boots. So the entropy in the kernel pool is minimal. It may be plausible for a remote attacker to guess the key for a bunch of servers.
Also, if the key is not rotated by cron, it provides a single-packet method for a remote attacker to observe that a server has been rebooted since he last checked. This will give a good indication of how often security patches have been applied.
http://git.kernel.org/linus/1046716368979dee857a2b8a91c4a883... http://git.kernel.org/linus/168a8f58059a22feb9e9a2dcc1b8053d... http://git.kernel.org/linus/8336886f786fdacbc19b719c1f7ea91e...