- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Thu, 18 Sep 2014 10:03:35 -0400
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNrdrBNi0kZDorR+8K-5-sPFipVr=U0kx5r56oPX_LhJSA@mail.gmail.com>
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
Received on Thursday, 18 September 2014 14:04:04 UTC