> Furthermore, the server should periodically change the encryption key used to generate the TFO cookies, so as to prevent attackers harvesting many cookies over time to use in a coordinated attack against the server.
What is going to do this? I hope this is built-in somehow.
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...
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.
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.
Of course, some will argue that if the attacker is inside your NAT, you're already pwned.
I don't think that's a very good principle for the security design of internet protocols.