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

I have been looking through the archives and I can't seem to find the 
discussion about how this requirement came about, and I am really 
struggling to understand why it is necessary.

I can't really see how it provides any increased security, given that if 
a cypher that meets these requirements is not available the client is 
expected to fallback to HTTP/1.1 and communicate over the supposedly 
less secure cypher anyway.


Martin Thomson wrote:
> On 17 September 2014 17:09, Greg Wilkins<>  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.

Received on Thursday, 18 September 2014 04:53:51 UTC