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.