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 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. There are two problems here - one is the debate about if we should be doing TLS restrictions in the first place. The other is about designing a good handshake. Currently the handshake is not a good design and relies on expected evolution of ciphers into the future an norms of configuration to make it work. If the spec at least designed a handshake that was robust, I would be a lot less strident about my opposition to this social engineering experiment. regards -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Tuesday, 23 September 2014 18:27:52 UTC