- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 24 Sep 2014 00:05:17 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Eric Rescorla <ekr@rtfm.com>, Jason Greene <jason.greene@redhat.com>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 23 September 2014 11:27, Greg Wilkins <gregw@intalio.com> wrote: > On 23 September 2014 18:06, Martin Thomson <martin.thomson@gmail.com> wrote: >> >> That is precisely what 9.2.2. does: >> >> * MUST ephemeral >> >> * MUST NOT block or stream cipher > > but it also lists exceptions for ciphers like AES GCM, which is a block > cipher. Also this language does not help you if all you have is the cipher > name. Unless we create an IANA register of h2 (un)acceptable cipher names GCM is an AEAD cipher. > On 23 September 2014 19:16, Martin Thomson <martin.thomson@gmail.com> 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. > > Sorry but it does not help at all. An ordered array with an undeclared > break between good and bad ciphers still needs the server to be able to run > an isAcceptableToH2 method to determine the break. If I have that method, > then ordering is not necessary. Of course it works. A Java (<=7) server picks the first suite that it supports from the list offered by the client. An h2 compliant client is required to offer at least one valid suite that an h2 compliant server is required to support, so this can't possibly result in a "bad" suite being selected.
Received on Wednesday, 24 September 2014 07:05:45 UTC