Re: 9.2.2, Rough Consensus, and Working Code

Mike,

I think Jetty is currently in the cannot and will not implement 9.2.2
camp.   The posting you linked to said:

Give me a robust handshake - any way you see fit, and then I will make a
best effort attempt to implement 9.2.2.

The reason for this is that without a robust handshake, then any partial
attempt to implement 9.2.2 is just going to result in handshake failure if
there are differing interpretations of the cipher restrictions.     So
given that handshakes will fail, we prefer to be able to say to frustrated
users "they are failing because the browser is insisting on offering weak
ciphers in a h2 handshake just so that they can avoid extra latency when
talking to old h1 servers".    To attempt a partial 9.2.2 implementations
will just result in involving those frustrated users in replay of all the
in depth cipher discussions that have happened here.

However, if the handshake is robust, then we are prepared to make a best
effort attempt at restricting the ciphers along the lines recommended here
(even though we do not think it is the applications protocols business),
because we know we can make a best effort attempt and not fail in the
handshake.

So your proposal of relaxing MUSTs to SHOULDs does not address my
fundamental concern of a fragile handshake.

Let's fix the handshake and then and only then can we reach a reasonable
compromise on cipher restrictions.  Without a robust handshake, Jetty will
just not go there.

cheers








On 5 November 2014 12:42, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

>  By my count, the following implementations have working code or stated
> plans to implement the restrictions in 9.2.2:
>
> ·        Chrome/Google -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0148.html
>
> ·        Mozilla Firefox -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0143.html
> among others
>
> ·        Jetty –
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0190.html
> (best effort, can’t fully match)
>
>
>
> The following have stated that they cannot or will not implement 9.2.2:
>
> ·        RedHat -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html,
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0014.html
>
> ·        Apple -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html
>
> ·        Apache -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html
>
> ·        Wildfly -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html
>
> ·        HAProxy -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html
>
> ·        Microsoft (IE, IIS, etc.)
>
>
>
> (If there are other implementations on either side, my apologies for
> missing you in my survey – please reply and voice your plans.)
>
>
>
> Microsoft also has no current plans to implement the restrictions of 9.2.2
> in client or server stacks.  We fully support this guidance as a best
> practice, and our default configuration will be compliant 99+% of the
> time.  However, we don’t wish to restrict the admin’s ability to change the
> default configuration based on local knowledge or our ability to change the
> defaults in the future based on new information.
>
>
>
> Jason has described the abilities that would have to be added to TLS (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to
> support the proposed requirements, which are essentially that ALPN
> selection implies restrictions to the cipher suite selection (or vice
> versa).  There’s nothing in the TLS or ALPN docs that suggests cipher suite
> selection has anything to do with ALPN protocol selection.  We still
> believe that documents specifying new TLS behavior should come from the TLS
> WG and be implemented in the TLS stack.
>
>
>
> I’ve given RFC 7282 a read (and anyone who hasn’t done so this week,
> please do), and I personally have to concur with Martin’s assessment – we
> have no consensus to keep 9.2.2 in the spec as written.  However, I also
> believe Mark is correct that there remains a valid objection from those who
> want to see it included (including some outside this WG).
>
>
>
> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to
> SHOULDs.  I’ve prepared a pull request to this effect at
> https://github.com/http2/http2-spec/pull/641.  Either TLS implementation
> is free to only offer or accept cipher suites they’re comfortable with,
> regardless of protocol, but there is no technical reason that these cipher
> suites are the only ones that MUST ever be used when HTTP/2 over cleartext
> is acceptable and HTTP/1.1 over other cipher suites is acceptable.
>
>
>



-- 
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.