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: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 5 Sep 2014 00:24:58 -0700
Message-ID: <CABkgnnXrrnnMkToCinOmSe7y4VkqfFZZ_N9GuYJt+2xb9o4wUQ@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 4 September 2014 19:12, Greg Wilkins <gregw@intalio.com> wrote:
> Thus I don't have the information available to exclude h2-14 from the
> protocol list on the basis of negotiated cipher.

The server selects both ALPN and cipher suite.

If ALPN is picked first of those two in the OpenJDK implementation,
that's fine, as long as the cipher suite selection is OK.

A client offering "h2" should be including valid choices, so the only
problem is tweaking the suite selection process somehow.  In NSS,
there's a list of supported and enabled suites from which the server
picks the first available.  Ensuring that valid choices appear before
invalid ones will make software like that produce the right outcome.

It looks like OpenJDK does the same based on the order of
preferLocalCipherSuites and getActiveCipherSuites():

If you have preferLocalCipherSuites off, you should be OK with Firefox
as long as the necessary suites are enabled, but I'd want to turn it
on to avoid problems.  There might need to be some other tweaks to
enable ECDHE, I know that Chromium had some issues when in the server
role for DTLS because it's not on by default in OpenSSL/BoringSSL.

INADEQUATE_SECURITY is there as a backstop, should this process fail.
I don't see any reason why it should be necessary if you are correctly
Received on Friday, 5 September 2014 07:25:26 UTC

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