Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On 24 September 2014 02:39, Simone Bordet <> 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