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: Brian Smith <brian@briansmith.org>
Date: Wed, 17 Sep 2014 12:02:52 -0700
Message-ID: <CAFewVt7+UAJYfKAR6DRZi_mqdzSaYw6L-pT1qg=UyOaP1ojhTw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 17, 2014 at 3:05 AM, Greg Wilkins <gregw@intalio.com> wrote:
> If at some time in the future the client and server interpret 9.2.2
> differently the then current available ciphers, then it is possible for the
> server select, in good faith a cipher that it thinks is h2 acceptable, but the
> client does not.

I think you can expect that browsers will not enforce requirements
stricter than what draft 14 requires.

> Worse yet, a server has to deal with multiple user-agents out there, that
> might eventually have different interpretations of what an acceptable h2
> cipher is.

This would be a bug in the client. I don't think it is worthwhile to
worry about such buggy clients.

> But my question is, how do I keep that regex and hard coded requirements
> up to date with all browsers out there? What mechanism is there to ensure
> that we all update our regex's and code in lockstep?

"If the client offered the cipher suite in its ClientHello, and the
cipher suite fulfills the requirements imposed by the HTTP/2 spec,
then assume the client will accept it for HTTP/2. Otherwise, don't."

> 9.2.2 is too vague and terms like "such as" are not defined in RFC2119

draft 14 is clear enough for me to classify cipher suites into
"acceptable" and "not acceptable". By default, assume that a cipher
suite is not acceptable and you'll be fine.

Cheers,
Brian
Received on Wednesday, 17 September 2014 19:03:20 UTC

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