W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Simone Bordet <simone.bordet@gmail.com>
Date: Thu, 18 Sep 2014 18:20:21 +0200
Message-ID: <CAFWmRJ2zq2TOotgNhHNNoPMWfov8_T+ukN_o0Bq8NmaMXZKqEQ@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi,

On Thu, Sep 18, 2014 at 4:03 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 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.

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 ?

Thanks !

-- 
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 Thursday, 18 September 2014 16:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:38 UTC