Re: Concluding discussion on #612 (9.2.2)

On 8 October 2014 09:10, Martin Thomson <martin.thomson@gmail.com> wrote:

> I suspect that no browser can implement that requirement and remain
> competitive.


I don't accept that this whole mess is because the browser vendors are
unwilling to risk their commercial concerns to achieve good security
practises.    I am sure there is a win-win solution where the IETF can
achieve our goal of technical excellence and the browser vendors can
achieve commercial success.

To borrow a metaphor used already used on this subject:  The current 9.2.2
is holding h2 as hostage to try to enforce good ciphers.  This proposal is
for a hostage exchange of h1 for h2.  Instead of threatening to kill the h2
hostage in a game of Russian roulette , this proposal is just to slow down
the h1 hostage only if it insists on using weak ciphers.

If we want to encourage both good ciphers and h2 adoption, then let's not
set them up in competition to each other.   Instead, let's add an impost to
weak h1 servers to encourage them to move to better ciphers.

It is not acceptable to have a fragile handshake and many implantations
have already declared they will not implement 9.2.2 as is. So if this
proposal for a robust handshake is not acceptable to browser, then please
propose an alternative that is because the status quo is not.

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.