1. Summary
"False Start” was an attempt to reduce the latency impact of HTTPS based on the simple premise that the client send application data earlier in the handshake; to be precise clients send application data before they have received and verified the server's "Finished” message. Initial measurements showed a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the implications at the end of s2.
Note that this “experiment” was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some additional details:
- Chrome 20 disable it except for sites that enabled NPN.
- Firefox has (or at some point had) an NPN requirement to enable False Start.
- Safari as an additional example without the NPN requirement:
http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslTransport.c
- While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official release.
As far as where you should point your fingers:
- Sean Turner is the document shepherd, and;
- Stephen Farrell is the responsible Area Director.
2. Review and Consensus
There wasn’t a whole lot of discussion, primarily because "False Start” the implementation issues were worked out by the browsers and the WG didn’t adopt this draft until long after (Nov-2014). The draft was adopted because it documents existing practices and provides security considerations [0]; the comments in the WG adoption thread were incorporated in the -01 WG version. The WG’s deliberations resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3).
One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade protections defined in [1] are in adequate. To solve address this issue, the “False Start” draft requires whitelists as well as large groups/curves.
[0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
RFC Editor Note
RFC Editor Note
Please change the intended status in the header to "Informational"
I don't believe any other text changes are needed. (The IESG and
authors figured that informational was better during IESG eval.)