W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Michael Sweet <msweet@apple.com>
Date: Fri, 05 Sep 2014 11:26:59 -0400
Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <7A8D7746-C8EE-4ADC-B7FB-CE18B26FE394@apple.com>
To: Patrick McManus <mcmanus@ducksong.com>
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

Received on Friday, 5 September 2014 15:27:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC