- From: Michael Sweet <msweet@apple.com>
- Date: Tue, 23 Sep 2014 05:01:46 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- 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>
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