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

Patrick,

The reality is that many h2 implementations will not have access to their
TLS layer in any meaningful way other than getting either a list of
available cipher names or the name of the selected cipher.   It does not
help us to deny that reality.

A server receives an array of ciphers from the client, let's say they are
well ordered so the h2 acceptable ones are at the front and the
unacceptable ones are at the end.  The server does not know where in that
list the browser has decided to make the break, so I can't just
mechanically remove the ciphers that my deployment thinks are unacceptable
and then select element [0].
(suggestion 1 - send separate cipher arrays for each protocol)

I have to re-evaluate each cipher myself to test if it is h2 acceptable and
I have to do so in a way that will always produce the same answers as the
client used, else I fail to connect. (suggestion 2 - define a retry
mechanism without unacceptable ciphers instead of just failing).

I may not have access to the local TLS implementation, so generally at best
all I have is the cipher name.   Sure I can come up with a regex that works
mostly today, using the wikipedia list of AEAD cipher names.   But such an
implementation will not change in lock step with the entire browser
population, so connection problems will result.  Even if I make the list
configurable, then that is still insufficient as if clients change their h2
acceptability list at different times, server configuration will have a
choice of not talking to a subset. .

If I have access to the TLS implementation, the questions I need to ask it
about the ciphers are not clear, as I doubt they have methods like
isBlockCipherButNotOneSuchAsGCM(). (suggestion 3 - improve the language in
9.2.2 to be more precise).  Also i am querying the server TLS impl which
may still differ from the client TLS impl.

regards







On 23 September 2014 10:20, Patrick McManus <mcmanus@ducksong.com> wrote:

>
> On Mon, Sep 22, 2014 at 7:40 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>> interop problem is discovered
>
>
>
> We don't have agreement that there is a problem here - your argument is
> based around a world in which h2 doesn't know anything about the TLS
> algorithms it is using and that just isn't how h2 is defined. Its expected
> that frameworks will have some catching up to do - we've seen that progress
> happen with ALPN already.
>
> And to bump this up the stack a bit, this is really quite a useful
> provision of h2. It is a waypoint for jettisoning stuff that we can't kill
> for reasons of backwards compatibility (at least without a lot of pain) but
> best practices tell us we shouldn't be using.
>
> -P
>
>


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