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: Michael Sweet <msweet@apple.com>
Date: Tue, 23 Sep 2014 05:01:46 -0700
Cc: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, Eric Rescorla <ekr@rtfm.com>, Jason Greene <jason.greene@redhat.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <950CF94B-0C45-497E-B2CF-3AF836A55599@apple.com>
To: Martin Thomson <martin.thomson@gmail.com>
Martin,

Apple's TLS implementation provides API to get/set the list of cipher suites but makes no guarantee or statement about the order being significant.  So to be honest I don't know whether the ~900 million iOS and OS X clients out there will be able to play the cipher suite games needed to opportunistically establish a HTTP/2 connection and gracefully fall back to HTTP/1.1 - will report back when I have something more definitive...


> On Sep 23, 2014, at 2:16 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> On 22 September 2014 15:55, Mark Nottingham <mnot@mnot.net> wrote:
>> One thing that I’ve heard is requiring clients to offer the “good” suites first, to promote interop. Does anyone see a downside to doing that?
> 
> It would definitely solve Greg's issue with Java <= 7.
> 
> The only case where this wouldn't work is where clients are unable to
> alter the priority order of cipher suites.  I don't know if any of
> those exist; I haven't met one yet, though I anticipate an
> introduction shortly...  The worst failure mode here results in a
> fallback - once you discover that the server supports HTTP/2, you can
> kill off the bad suites and try again.
> 
> That seems to be the only concrete technical concern I've seen raised
> in the discussion.  I think that Eric has addressed most of the
> process concerns.
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 23 September 2014 12:02:26 UTC

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