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

On 17 September 2014 17:52, Brian Smith <> wrote:

> By the way, the browser has to do the same thing, in order to decide
> which cipher suites to block for HTTP/2, and they manage just fine.


the problem is not coming up with an algorithm to decide on what
ciphers are acceptable.  The problem is coming up with EXACTLY THE
SAME algorithm as all clients to decide what ciphers are acceptable.

If at some time in the future the client and server interpret 9.2.2
against the then current available ciphers, then it is possible for the
to select, in good faith a cipher that it thinks is h2 acceptable, but the
does not.  The result is GO_AWAY and no retry.

Worse yet, a server has to deal with multiple user-agents out there, that
eventually have different interpretations of what an acceptable h2 cipher
The server is then going to have to do user-agent guessing before it has
accepted a connection from the client!  Ugh!

So yes I mostly fix this today, with a regex or by hard coding some AEAD
requirements in the same way that FF has done.    But my question is,
how do I keep that regex and hard coded requirements up to date with all
the browsers out there?   What mechanism is there to ensure that we all
our regex's and code in lockstep?    If we can't update in lockstep, then
this problem is again going to cause communication failures.

So I can't simply write a patch, unless I know that all client vendors are
simultaneously write and release the same patch for their product and the
universe turns it on at precisely the same time!

Actually, even today, if presented with some funky ciphers like Ilari has
how do I know that I've implemented 9.2.2 exactly the same as FF and that
they have
it exactly the same as Chrome, Opera, etc.?  9.2.2 is too vague and terms
like "such as" are not defined in RFC2119

Greg Wilkins <> HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Wednesday, 17 September 2014 10:05:39 UTC