Re: #612: Adopting pull #644

For me, these are the magic words in the PR:

Endpoints MAY choose to generate a <xref
target="ConnectionErrorHandler">connection
error</xref> of type <x:ref>INADEQUATE_SECURITY</x:ref> if one of the
prohibited cipher
suites are negotiated. However, implementations MUST NOT generate this
error in
reaction to the negotiation of a cipher suite that is not in the prohibited
list.
Consequently, when clients offer a cipher suite that is not prohibited,
they have to be prepared
to use that cipher suite with HTTP/2

I believe this fixes the fragile handshake problem.  It thus allows
implementers/deployers to be as rigorous or as flexible as they like in
their implementation of 9.2.2 without risking communication failure.

So despite the hacky feel of a large immutable black list, that's a erk I'm
willing to put up with if the browser implementors really do require no
extra latency on h1 connections with weak ciphers.

So looks good to me.

cheers



On 19 November 2014 05:45, Yoav Nir <ynir.ietf@gmail.com> wrote:

>
> > On Nov 18, 2014, at 8:03 PM, Jason Greene <jason.greene@redhat.com>
> wrote:
> >
> > “unless a deployment is restricted from doing so by factors outside the
> scope of this document” :)
>
> Finally, a category that includes OpenSSL APIs and the Russian government.
> :)
>
> Yoav
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.