Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

FWIW, there are lots of (non-TLS) RFCs that have been published with explicit TLS requirements over the years, but I am not aware of a single RFC or WG that hasn't regretted doing so because such requirements are made by non-experts and are quickly made obsolete by changes in TLS or new security vulnerabilities.

Publishing hard TLS/1.2 requirements (beyond a reference to RFC 5246) in HTTP2 would be, IMHO, a big mistake, particularly when the TLS WG is chartered to "deliver" 1.3 in November.  Plus, by allowing any conforming TLS/1.2 (or higher) implementation to be used for HTTP/2, you reduce the number of implementation issues (such as being discussed here) and allow future changes to TLS without needing to update HTTP/2 just to keep up.


On Sep 5, 2014, at 11:03 AM, Patrick McManus <mcmanus@ducksong.com> wrote:

> 
> On Thu, Sep 4, 2014 at 9:05 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which would be acceptable if the protocol was https, but because it is h2,  FF fails the connection due to lack of AEAD.     This results in a connection failure on the client, when it would have worked fine if http/1.1 was accepted as the protocol instead.
> 
> right. h2-14 requires aead and the server selected h2 via alpn without also using aead - so that's a h2 level protocol error on the server's part and that connection can't proceed. The expected thing would have been for the server not to select h2.
> 
> The question of what to do next in the client is tricky and fun to talk about, but I think the standard does the right thing by steering clear of it. As you note, firefox right now declares game over - hard fail. No doubt the error page for it is in dire need of improvement :)
> 
> One part of that decision is the nature of the specific failure - auto fallback to a less secure suite from a server that indicated it was capable of a stronger suite (by signaling h2) has the hallmarks of a downgrade attack. scary stuff.
> 
> The other part of that is just design experience that favors being intolerant of errors - especially at early stages. These workarounds tend to get added over time for bugwards compatibility,, but at this stage we shouldn't feel that kind of pressure - its much more important to build an ecosystem where things operate correctly when its full of those kinds of written and unwritten rules. A lot of folks believe we're in an era where "be liberal in what you receive" is no longer in the best interest of the Internet.
> 
> I do agree this is tricky to get right (but worthwhile!). We had a bug where we would occasionally send a TLS 1.0 client hello (due to some tls intolerance logic) with h2 in the offer list. If h2 was selected, we generated an error. We shouldn't do that - they aren't compatible.
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair