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: Wed, 24 Sep 2014 02:52:58 -0700
Message-ID: <CABkgnnWgbrsex+kXhWrAsBCsQ0-PUVSEZGN7D+PLmzcBX9yCkg@mail.gmail.com>
To: Simone Bordet <simone.bordet@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
On 24 September 2014 02:39, Simone Bordet <simone.bordet@gmail.com> wrote:
> Are you suggesting that every h2 client must be modified (and
> recompiled if it needs to) every time a new cipher is provided by TLS,
> or I totally misunderstood you (sorry if it is so) ?

The software that enables a new cipher suite has to know if it is
acceptable to h2 or not before it offers it in a handshake that might
result in h2.  The acceptability test will depend on implementations.
Some TLS stacks don't let you interrogate a cipher suite to determine
if it is acceptable, others do.  For those that permit querying suite
metadata (see ekr's post about NSS), then all that is needed is logic
like so:

  h2acceptable = !isStream && !isBlock && isFsCapable

If that is not possible for some reason (c.f., Java) then you will
need to revise the implementation to ensure that new suites don't
materialize.  The easiest way to do that is to list the suites you
know are OK and include a list of those.  That means respinning your
code to take advantage of new ciphers.

What you want to avoid is the new cipher being like this one I've
heard about: TLS_ECDHE_RSA_ROT13_CRC32
Received on Wednesday, 24 September 2014 09:53:25 UTC

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