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

On 18 September 2014 12:14, Martin Thomson <martin.thomson@gmail.com> wrote:

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

Well leaving aside the aspect of requiring support for all time for a
security cipher....

My example is not saying that GCM has been revoked, only that a better
version called XYZ becomes available.

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.
>

Exactly my point!!!!  If implementations pickup XYZ and some
know it is OK but some don't, then we have connection failure.

NOT fallback to GCM

NOT fallback to http1

It is GO_AWAY with no retry.  Game Over!

Server can't be smart and pick a workable protocol+cipher combination
because
it is impossible to know what all clients out there think is an acceptable
protocol+cipher combination.

Thus you are saying that it is sadly expected behaviour that we have built
in a
total protocol failure at some future date when there is a better cipher
suite
than GCM available.


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.
>

It is not about tricking the selection to make it work.  It is about
designing
a standard that wont fail given normal expected conditions.

Note also that we are in discussions with the OpenJDK developers about
their ALPN
implementation.  They are pushing back about allowing ALPN extension to
influence
the cipher selection.

Also note that the problem with java 7 is that it doesn't provide any GCM
ciphers at all:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html

So part of the problem that h2 cannot be deployed on java 7 (which I think
is a pretty
big deficiency, but not what I'm currently raising).

I understand that 9.2.2 requires us to support GCM, but the example of
moving from
java7 with CDC to java 8 GCM has shown a real interoperability problem as
we lost
connectivity with FF because it has implemented the GCM restriction before
we have.
We could implement the GCM restriction, but then nothing is stopping the
same
complete failure when XYZ eventually comes along.

I've got to this point because I have been trying to implement the GCM
restriction
in jetty, but am unable to provide and implementation to

   public static String[] getH2AcceptableCiphers(String[] availableCiphers)
{}

that is robust in the face of arbitrary available ciphers.   Unless we
implement
exactly the same algorithm as FF, Chrome, Opera and all other clients, then
we will have communication failure.   If I make it a configuration lookup,
then
we will certainly have failures.

To remove any doubt whatsoever, I can absolutely can not live with 9.2.2.

regards

























-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.