[secdir] Secdir review of draft-ietf-tls-falsestart-01

[Charlie Kaufman <[e-mail]>]

This document specifies a performance enhancement to TLS that under certain circumstances could weaken security. Much of the document covers criteria for when it is "safe" to implement this optimization. It would be an optional behavior in TLS clients and requires no changes to TLS servers (except see below). This I-D is proposed to be an Experimental RFC.


This enhancement has been proposed before, but rejected because of the possible security exposures. Nevertheless, because it can be implemented unilaterally in the client, I would be surprised if some implementations were not doing it. The performance benefit is the savings of a network round trip, which is generally small but it could make a human detectable difference in the rate at which interactive content loads, and this could be seen as a competitive advantage.


The advantage of having such a document published is that people considering making this change could easily learn the security dangers of doing it and make an informed decision.


Some nits:


Section 3 talks about determining whether a TLS server is "false start compatible". I believe any server that correctly implements TLS (i.e., following the specification) would be false start compatible. That does not imply that all would be, and it would be useful to do some testing to see whether most implementations in fact are. Publishing this as an experimental RFC is likely to encourage such an effort.


Section 2 paragraph 1 says that TLS requires two full protocol rounds before the handshake is complete. While technically this is true, it overstates the benefit of this enhancement because TLS rides atop TCP which has its own protocol round before it starts carrying application payloads. So this enhancement reduces that TLS startup time from three round trips to two rather than the more dramatic two to one.