Re: #612: 9.2.2 requirements

> 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 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#ref-TLS-ECDHE>] with P256 [FIPS186 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#ref-FIPS186>].”

which, by the way, it has said as long as I can remember. Thus, we always will have a cipher suite that implementations advertising “h2” can agree on. If that cipher suite, at some point in the future, becomes unsatisfactory, then we will update the RFC, and make the new RFC require a new ALPN token. Problem solved.

Everything else in 9.2.2 is basically just saying if you want to use a cipher suite that’s NOT the one mentioned above, AND you’re using TLS 1.2, then it has to meet certain requirements (which the specified cipher suite does, in fact, meet).