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: Roland Zink <roland@zinks.de>
Date: Wed, 24 Sep 2014 11:05:31 +0200
Message-ID: <5422895B.2010104@zinks.de>
To: ietf-http-wg@w3.org
On 24.09.2014 10:54, Eric Rescorla wrote:
>
>
> On Wed, Sep 24, 2014 at 1:43 AM, Roland Zink <roland@zinks.de 
> <mailto:roland@zinks.de>> wrote:
>
>     On 24.09.2014 09 <tel:24.09.2014%2009>:02, Eric Rescorla wrote:
>
>         I'm sorry, I'm not following this point.
>
>         Say that someone invents some new cipher suite, X. It's either
>         acceptable for h2 or it's not [0]. The client then behaves as
>         follows:
>
>         - If it is acceptable for h2, the client offers it, since
>         everything is
>           fine.
>         - If it's not acceptable for h2, the client offers it, secure
>         in the
>           knowledge that a conformant server will (per 9.2.2) not
>         negotiate
>           it for h2.
>
>         As far as I can tell, either of these is fine. Do you disagree?
>
>     When h2 is upgraded to allow X (per 9.2.2X) then an old client
>     offering X only for some other protocol will not work with a new
>     h2 server as it will reject based on 9.2.2.
>
>
> Wait, how does this happen? When we introduce X we label it as acceptable
> for h2. Old clients won't offer X because they won't have it and when they
> do have it they should know it's acceptable for h2.
>
> -Ekr
Old clients may already have it in use for something different then h2, 
for example h1. It is specifically disabled for h2 in the client because 
of 9.2.2. Then you label it acceptable for h2 but this doesn't mean that 
the client code is updated.
Received on Wednesday, 24 September 2014 09:05:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC