Patrick, 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