FalseStart - another protocol tweak that failed

[Mike Belshe <[e-mail]>]

This is slightly off topic from HTTP/2.0, but has a relevant theme.

If you're not familiar with False Start, its a minor, protocol compatible
implementation tweak to the TLS handshake which has spectacular performance
results and works for 99+% of all existing SSL implementations.  It has
been enabled in Chrome for over a year and has demonstrated fantastic
performance benefits.  Sadly, it is being disabled soon due to a small and
untractable number of sites that have SSL implementations which can't be
readily fixed nor identified.

Here is the recent news about FalseStart:
   http://www.imperialviolet.org/2012/04/11/falsestart.html

Here is some of the benefit of FalseStart:
   http://www.belshe.com/2011/05/19/ssl-falsestart-performance-results/

Here is the FalseStart description:
   https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

*What we can learn from this:*
a) Running new protocols, or even existing protocols with new patterns, is
very fragile on today's internet.

b) Compatibility is key.  Even a tiny fraction of users being broken will
be enough to kill the protocol by way of browser disablement.  Pipelining
and FalseStart are just two examples.

c) Being able to identify hosts that fail on any new protocol is unlikely.
 We often use wishful thinking that we can identify bad hosts via
blacklists or fast-fail mechanisms.  However, past experience shows that
while you can identify most problems, you probably can't identify all
problems, and even a small number of problems is enough to torpedo the
whole thing.

d) Internet problems are global.  While we might write up the problem and
solution in English many times, for the folks not speaking English, it
takes much longer for them to learn about any changes we make.  This makes
it harder for them to identify when they have a problem and also harder for
them to identify how to solve it.

Mike