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

Hi,

On Wed, Sep 24, 2014 at 11:52 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> The software that enables a new cipher suite has to know if it is
> acceptable to h2 or not before it offers it in a handshake that might
> result in h2.  The acceptability test will depend on implementations.
> Some TLS stacks don't let you interrogate a cipher suite to determine
> if it is acceptable, others do.  For those that permit querying suite
> metadata (see ekr's post about NSS), then all that is needed is logic
> like so:
>
>   h2acceptable = !isStream && !isBlock && isFsCapable

Ok, this will be out of date any moment a new algorithm is discovered,
and would require modify the source (and recompile).

Also, I understand it right that the logic above will apply to all
protocols spoken by the client, not only h2 ?
That is, the client can only offer ciphers that are h2 acceptable,
even if the server does not speak h2, and even if the server picks
another protocol.

A polyglot h1, h2 client correctly configured that tries to connect to
an old server won't be able to establish a connection speaking h1
because the old server won't know the new ciphers (e.g. web spiders).

Using only h1 would remove the restriction and allow connectivity to
any server, but of course it's bad for h2 adoption.

Thanks !

PS: sorry for asking so many clarifications about this, but I'm
working with the OpenJDK security team to design an API for ALPN with
the idea to support HTTP/2.
As it is now, an ALPN API is not enough to support HTTP/2, as the JDK
would also require an API to query cipher metadata, so bear with me :)

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

Received on Wednesday, 24 September 2014 10:44:17 UTC