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

[Martin Thomson <[e-mail]>]

On 17 September 2014 17:09, Greg Wilkins <[e-mail]> wrote:
> Consider clients and servers written in java, so they inherit their ciphers
> from the JVM. At some stage in the future a GCM is replaced by XYZ and added
> to the JVM, so it is part of the acceptable TLS ciphers, but the h2 clients
> and servers implementations have adopted your advice to "By default, assume
> that a cipher suite is not acceptable".   So everybody is assuming that XYZ
> is not h2 acceptable.

You can't suddenly pull a cipher suite that people rely on.  We rely
on GCM.  We require that implementations support it.

Yes, there will be implementations that pick up XYZ, but also don't
know that it's OK.  That's expected behaviour sadly.  Not all
implementations will be able to examine the properties of the
available cipher suites and use properties to determine if they are OK
to use.

> This is not a theoretical problem.

I disagree, it's a hypothetical problem.

> It is a real problem that I have
> experienced as FF rolled out their AEAD restriction as rqeuired by 9.2.2
> before jetty had implemented the same restriction and while AEAD is not
> available on java-7.  I could implement the AEAD restriction in jetty now to
> get connectivity with FF, but would lose connectivity with h2 clients
> running java-7.

I'm not sure that this is quite right.  Unless the Java 7 code is
singificantly different to the Java 8 code, you should have been able
to influence suite selection so that a good suite (i.e., an acceptable
one) was chosen.