Re: 9.2.2, Rough Consensus, and Working Code

Greg,

This is one of the reasons why I proposed just keeping the "MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186]" requirement and dropping the rest.  That way HTTP/2 capable servers and proxies can continue to offer HTTP/1 compatible cipher suites to provide the best security and interoperability without hacks.


> On Nov 4, 2014, at 9:52 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 
> 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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 5 November 2014 03:56:14 UTC