Re: 9.2.2, Rough Consensus, and Working Code

Hey Mike,

One question - why did you change it so that only the client can generate INADEQUATE_SECURITY?

Also, it seems like this is orthogonal to Martin's proposal:
  https://github.com/http2/http2-spec/pull/615

What do people (including you, Mike) think about combining them (perhaps without the change above, unless we can motivate it)?


  
> On 5 Nov 2014, at 12:42 pm, 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 athttps://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.

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 5 November 2014 22:32:49 UTC