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:29:46 -0400
Cc: Simone Bordet <simone.bordet@gmail.com>, Greg Wilkins <gregw@intalio.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <79D552C8-587F-4B7C-BAFE-FB09A30D1812@apple.com>
To: Patrick McManus <mcmanus@ducksong.com>

On Sep 5, 2014, at 11:15 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> On Fri, Sep 5, 2014 at 9:53 AM, Simone Bordet <simone.bordet@gmail.com> wrote:
> If tomorrow those ciphers are discovered flawed or better ones
> invented, why should the HTTP/2.0 specification be modified at all ?
> The intent of the existing text is to provide minimum requirements for use of a new protocol. If new approaches become a best practice in the future they can be used with h2 (without modifying the h2 definition) as I understand it. I'm sure Martin would entertain changes to the text to help make that clear. And sure, as time goes by we will have problems along the lines of "X is now known insecure, do I need to keep accepting it for backwards compatibility" - but we don't have to start by allowing X=RC4-SHA1 on day one.. this will help clear the decks of accumulated cruft, which is worthwhile even if more cruft will inevitably arrive.

The TLS WG already has a draft outlawing RC4 for TLS/1.2.  And the UTA WG has a draft documenting the best practices for deployment.  There is no need for HTTP/2 to say anything about allowed or required cipher suites.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Friday, 5 September 2014 15:30:23 UTC

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