- From: Greg Wilkins <gregw@intalio.com>
- Date: Sat, 27 Sep 2014 07:04:41 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NEvsTaZQpfAajycuo9xqKqd3Pu9aCtVGZLZez7Ux=p+Yw@mail.gmail.com>
On 26 September 2014 18:08, Martin Thomson <martin.thomson@gmail.com> wrote: > I believe that these changes resolve the issues people have raised. Those changes are indeed better, but they don't totally address my concerns about the fragility of the handshake. They do greatly reduce the probability that the handshake fragility will be a problem, but only on the basis of assumptions of how the evolution of TLS1.2 ciphers will progress, plus hope that any configurability of ciphersuites will always be done in accordance with the principles of 9.2.2 Who is to say that a crypto emergency wont arise that requires the deployment of TLS1.2 ciphers that are unknown for the purposes of the http2 implementation? If cipher evolution does not pan out as expected and deployers are forced to bend whatever rules they can with configuration, then we still may have interoperability problems. So while I don't oppose those changes, I still do not think they go far enough as the handshake is still fragile - they just reduce the fragile surface. I think that we either we need a handshake that clearly identifies the break in the offered ciphers between acceptable and unacceptable.... or we need an explicit white list of unacceptable h2 ciphers that may be offered for h1 fallback. 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 Friday, 26 September 2014 21:05:09 UTC