The False Start IETF draft (currently submitted to the TLS WG) is here: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

Brief summary: False Start TLS makes it legitimate to send the payload of a connection before the handshaking is finished. This improves latency, apparently doesn't make keeping track of state more complex, but does have security consequences. False Start can be piggy-backed onto regular TLS fairly easily, with fairly few pathological cases.

What do you mean by security consequences? As far as I can tell, the IETF draft specifies the whitelisted ciphers and key exchange algorithms for which False Start has no security consequences; as long as implementations use False Start only for those whitelisted algorithms, security isn't compromised. I suppose the only security consequence then is that bad implementations might choose non-recommended algorithms in their whitelists, either out of ignorance or because they are consciously compromising security for the sake of being able to use False Start more often.

The security consequence discussed in the draft is that since handshakes validate, allowing the protocol to bypass them undermines authentication, giving more opportunity to construct, say, man-in-the-middle attacks.

There is no whitelist of algorithms. The discussion talks generally about how to patch up this authentication problem, but it doesn't go into much detail. Ignorance is really our default state when it comes to security.

Yeah, they say they reduced the latency by 30% for 90%, but they actually increased it for 90% of sites I visit. Canary seems to be better in many cases, but still incomparable to FF4. On win7.