Last Call Review of draft-ietf-tls-falsestart-01
review-ietf-tls-falsestart-01-secdir-lc-kaufman-2016-04-14-00

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.