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

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

> That is precisely what 9.2.2. does:
>
> * MUST ephemeral
>
> * MUST NOT block or stream cipher
>
but it also lists exceptions for ciphers like AES GCM, which is a block
cipher.   Also this language does not help you if all you have is the
cipher name.  Unless we create an IANA register of h2 (un)acceptable cipher
names



On 23 September 2014 19:16, Martin Thomson <martin.thomson@gmail.com> wrote:

> > One thing that I’ve heard is requiring clients to offer the “good”
> suites first, to promote interop. Does anyone see a downside to doing that?
>
> It would definitely solve Greg's issue with Java <= 7.
>

Sorry but it does not help at all.   An ordered array with an undeclared
break between good and bad ciphers still needs the server to be able to run
an isAcceptableToH2 method to determine the break.  If I have that method,
then ordering is not necessary.

There are two problems here - one is the debate about if we should be doing
TLS restrictions in the first place.   The other is about designing a good
handshake.  Currently the handshake is not a good design and relies on
expected evolution of ciphers into the future an norms of configuration to
make it work.      If the spec at least designed a handshake that was
robust, I would be a lot less strident about my opposition to this social
engineering experiment.


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.