- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Thu, 18 Sep 2014 21:48:47 +0300
- To: Simone Bordet <simone.bordet@gmail.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Sep 18, 2014 at 06:20:21PM +0200, Simone Bordet wrote: > Hi, > > > > > 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. Also, can happen the other way: 1) Client prefers XYZ (9.2.2 compliant, and client knows that) over GCM. 2) Client offers both ciphers (with XYZ first) and both h2 and h1. 3) Someone has added XYZ to server TLS stack, and it picks first one it supports (XYZ), or server even prefers XYZ. 4) There is version skew and server h2 stack doesn't probe TLS stack, so server h2 stack doesn't know about XYZ -> generates INADEQUATE_SECURITY. > Any client that dynamically links the TLS implementation is subject to > this scenario, and certainly it's not an implementation bug in the > client if a deployer chooses to link that client to a newer TLS > library, no ? Furthermore, if using some general-purpose TLS stack, like GnuTLS, OpenSSL, LibReSSL, PolarSSL and couple others, such dynamic linking is best practice. I have seen version skew disabling features with both app and library from autoupdate. And also distributors patching applications and libraries for dynamic linking. -Ilari
Received on Thursday, 18 September 2014 18:49:13 UTC