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

Request Review of draft-ietf-tls-falsestart
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-04-20
Requested 2016-04-07
Draft last updated 2016-04-14
Completed reviews Secdir Last Call review of -01 by Charlie Kaufman (diff)
Opsdir Last Call review of -01 by Fred Baker (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Review review-ietf-tls-falsestart-01-secdir-lc-kaufman-2016-04-14
Reviewed rev. 01 (document currently at 02)
Review result Has Nits
Review completed: 2016-04-14

Review
review-ietf-tls-falsestart-01-secdir-lc-kaufman-2016-04-14









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.