On 24 March 2016 at 11:38, Bodo Moeller <bmoel...@acm.org> wrote: > The NPN dependency was a design decision for one implementation, but it's > not common to clients using False Start. For interoperability, you always > have to consider how to deal with what you expect to be deployed *currently* > (and NPN support certainly is one good indicator for False Start tolerance, > if you don't mind tons of false negatives), but I wouldn't see much value in > compiling the minutae of that in this kind of document: it'll go stale > quickly.
But I agree with this analysis, the original reason for the test was - if a little iffy - rational. Correlation might not imply causation, but sometimes correlation is all you need. BTW, Firefox still has the option to require that a site advertise NPN (or ALPN) before false starting. It's off by default and hard to find, but it's there. And there are still people who flip that bit. As a feature, it's not one we need to keep. I certainly wouldn't want to bless it by putting it in an RFC, Experimental or otherwise. Let's chalk that up to the ugly things we have to do to get things to work. Which reminds me... _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
