The TLS handshake is to work out identities and exactly what type of encryption etc they want/support. Then before sending any actual data they encrypt a "Finis

The TLS handshake is to work out identities and exactly what type of encryption etc they want/support. Then before sending any actual data they encrypt a "Finished" message and both sides verify they can read the message. The server will only be able to create a correct "Finished" message if it has the private key to go along with the presented certificate. It seems to me like the overt change in the handshake security boundary is that in a FalseStart handshake, a man-in-the-middle attacker can make the initiating side send application data encrypted with relatively arbitrary parameters (until the TLS implementation realizes it can't decrypt the final handshake message properly). There is a good chance this is just annoying (like, on a denial-of-service level of attack) but my intuition is there could be some application circumstances where this is a significant problem. Off the top of my head I can't come up with a specific example however - so I could just be imagining things :) There are also operating system/application level architecture challenges as well. For example, I'm not sure the idea of FalseStart is compatible with the calling convention of Windows SSL/TLS (InitializeSecurityContext and AcceptSecurityContext) given the separation between transport layer and security context negotiation components. And because of that existing convention, the recommendation in sections 4 and 5 of the draft that "TLS implementations allow the application layer to query whether the handshake has completed" could be potentially tricky for applications using Schannel (Windows SSL/TLS). "Creating an Schannel Security Context" : http://msdn.microsoft.com/en-us/library/aa374781(v=VS.85).aspx http://msdn.microsoft.com/en-us/library/aa374781(v=VS.85).as...