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.

Yep.

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.

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.