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

I have opened https://github.com/http2/http2-spec/issues/612 because this
issue has not been resolved enough for me to understand enough to implement
a working solution.

As well as my concern regarding the required capabilities of ALPN, I am
struggling to work out how to implement 9.2.2 and I think there are going
to be interoperability problems into the future. Specifically I think it
will become impossible for a client to ever exclude a cipher from h2
acceptability without risking communication failure.

The basic problem occurs if ever the client and server disagree on exactly
what is a h2 acceptable cipher.  The flow of the problem is:

   1. Client offers connection with a set CLIENT_OK_CIPHER which is the
   union of CLIENT_OK_TLS_CIPHERS and CLIENT_OK_H2_CIPHERS
   2. The server only sees the union set, so it does not know what ciphers
   the client think are h2 acceptable.  The server wants h2, so it picks a
   cipher from the intersection of CLIENT_OK_CIPHERS and SERVER_OK_H2_CIPHERS
   3. If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher may be
   picked that server thinks is h2 OK, but the client rejects because of it's
   interpretation of 9.2.2 at that time in the future.
   4. The client and server fail to communicate even though they have
   ciphers and protocols in common!

The only way to avoid this problem is for the client and server to
absolutely agree on what ciphers are h2 OK for all time and never ever ever
EVER disagree.     This might be possible if 9.2.2 is rigorously written in
a future proof way, but it is not:

   HTTP MUST NOT be used with cipher suites that
   use stream or block ciphers.     Authenticated Encryption with
   Additional Data (AEAD) modes, such as the Galois Counter
   Model (GCM) mode for AES [RFC5288] are acceptable.

So currently AES_128_CBC is an unacceptable h2 block cipher, but AES_128_GCM
is accepted.   Do I hard code that AES_128_CBC is unacceptable or that
AES_128_GCM is acceptable? If GCM is acceptable now, will GCM2 be
acceptable in the future?  As written this clause does allow for future
block ciphers with AEAD modes, but I don't know what they are in advance,
so I can't hard code them?  Will there ever be acceptable block ciphers
that use something other that AEAD?

Don't hard code I hear you say??? use a black/white list?????   Sure that
allows both client and server to future proof their users interpretation of
9.2.2, but that is now just subjective configuration and there is
absolutely no way that that client and servers will maintain the same h2
acceptable black/white lists.  If a client ever excludes a cipher from it's
h2 acceptable set before a server has, then communication failure will
result, even though client and server share acceptable ciphers and
protocols!
In short, to avoid communication failure, the server either has to just use
http/1 or it has to be absolutely sure it knows precisely what ciphers are
h2 acceptable to the client.   I am unable to implement that kind of future
proof telepathy and making it a configurable set just gives somebody else
the impossible task of knowing what is client h2 acceptable.

regards








On 6 September 2014 16:36, Greg Wilkins <gregw@intalio.com> wrote:

>
>
>
> On 6 September 2014 15:03, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>>
>> Preferable is subjective.  We've seen that demonstrated many times
>> where servers pick RC4 over better ciphers because ...well, I can only
>> speculate.
>>
>
> Exactly!  Sometimes infrastructure that is out of your control does things
> according to the standards that you would rather they didn't.
>
> I don't see how requiring h2 capable servers to sulk in protest and only
> serve h1 is going to help?   Just because browser vendors are unwilling to
> deprecate bad ciphers as it may affect their market share, you instead
> want servers to try to force change by withholding h2 services!
>
> It is a form of protest a-kin to holding your breath until you get your
> way!
> Nobody will notice the protest as the web will just work as it always has
> serving h1 over old ciphers.  Victory for the status quo!
>
>
> So we end up stuck with ciphers that are
>> sort-of-bad-but-not-broken-enough-to-pull.  Which sucks.
>>
>
> Sure that sucks, but I'm not sure it is our problem to fix.
> I want world peace too, but making that a requirement for using h2 is not
> going to help.
>
>
> <offtopic>
>
> It's not hard. ... You just need to know how to influence suite
>
> selection.... Do you want to break the web.
>
>
> Geeeeeeeeeeeeeeeeeeeeze you like to troll sometimes!
>
> I do know how to write code to pick something from a preference list....
> I had realised that cipher selection has something to do with this
> conversation.....   I spend all my free time in the WG in an effort to
> destroy web connectivity as we know it !)
>
> </offtopic>
>
> --
> 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.
>



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