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

Hi Greg,

This thread is suffering a bit from wall-of-text syndrome for me. Is this
the main point below?

On Thu, Sep 18, 2014 at 12:18 AM, Greg Wilkins <gregw@intalio.com> wrote:

>
> Exactly my point!!!!  If implementations pickup XYZ and some
> know it is OK but some don't, then we have connection failure.
>
>
The scenario as I understand it is:
1] some new XYZ is in fact h2 appropriate by 9.2.2,
2] a client handshake offers both XYZ and GCM along with h2 and h1
3] the server selects XYZ+h2 (which meet the requirements of h2 - good job)
4] The client's h2 stack, expecting GCM, is not aware that XYZ satisfies
9.2.2 so it generates an h2 INADEQUATE_SECURITY

I would say that's an implementation bug in the client.

I think its an interesting editorial point to call out that you really do
need to understand the properties of the ciphers you offer to negotiate
because of the constraints of 9.2.2 - at least along the dimensions that
9.2.2 deals with.


> it is impossible to know what all clients out there think is an acceptable
> protocol+cipher combination.
>
>
Implementations (and I think this applies equally to clients and servers)
are buggy if they generate INADEQUATE_SECURITY on connections that meet the
requirements of 9.2.2. This is not impossible to do right because the
negotiation is always an intersection of the things the client and server
both know. I acknowledge that some languages and frameworks will need more
work than others to satisfy it - I don't find that an especially important
argument in this context as we've already included requirements that
require significant changes to existing widely deployed frameworks (e.g.
ALPN).

I understand that 9.2.2 requires us to support GCM, but the example of
> moving from
> java7 with CDC to java 8 GCM has shown a real interoperability problem as
> we lost
> connectivity with FF because it has implemented the GCM restriction before
> we have.
>

I read this as you've had some interop problems because of buggy pioneer
implementations and evolving draft requirements - imo that's to be expected
at this stage of the process, not something to worry about maximizing
compatibility with. if the Java 7 app wasn't using an AEAD algorithm with
h2 then it was buggy, just like the old firefox nightlies that would allow
h2 to be negotiated with non-aead suites were buggy (I don't say that
pejoratively - bugs are just par for the course at this stage, its just
compatibility with buggy draft-level implementations doesn't really need to
be a constraint on the protocol definition.)

-P