Re: #612: 9.2.2 requirements

Nicholas,

> On Nov 1, 2014, at 12:42 PM, Nicholas Hurley <hurley@todesschaf.org> wrote:
> 
> 
>> On 1 Nov, 2014, at 05:14, Michael Sweet <msweet@apple.com> wrote:
>> 
>> However, in this case it seems that some feel that the mandatory cipher suite in TLS/1.2 is inadequate, and that a specific set of cipher suites is now preferred (and MAY be a requirement in TLS/1.3). Therefore, the proper, RFC 2119, approach would be to require support for one or more cipher suites that are seen as providing adequate security - that ensures interoperability and that the two end points will be able to negotiate a "secure" connection without requiring layering violations or causing interoperability problems.
> 
> Good news! Quoting 9.2.2:
> 
> "To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].”

I have no problem with this.  I *do* have a problem forbidding all of the other TLS/1.2 cipher suites (including the mandatory cipher suite in RFC 5246) which is a) not necessary for interop and b) causes interop and implementation problems.

Also, based on the traffic on the TLS WG list, it looks like TLS/1.3 will still include cipher suites that are not allowed by the current HTTP/2 text, but are otherwise considered "secure".  And thanks to the current wording, they will be valid when TLS/1.3 is negotiated but not TLS/1.2. (think of the interop issues there!)

Include recommendations if you must.  Explain the reasons for using particular kinds of cipher suites, or provide caveats that HTTP/2 over TLS has only had a crypto analysis with particular cipher suites, etc.  But don't lump on conformance requirements that will only hurt interoperability and deployment of HTTP/2.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Sunday, 2 November 2014 02:56:15 UTC