Code change:
This is based on the long set of negotiated changes added to . This adds the blacklist as Sam Hartman proposed at IETF 91.
Section 9.2.2 places restrictions on the ciphers that are acceptable for a http/2 connection that are different to the acceptable ciphers for a https connection that may be offered over the same handshake. To comply with 9.2.2, as server accepting an ALPN connection must either: a) influence the cipher selection to ensure an acceptable h2 cipher is selected; b) be informed of the cipher selected and if it is not acceptable then select http/1.1 instead of h2 as the protocol. Neither of these capabilities are required of a RFC7301 compliant implementation. Specifically there is no requirement for an ALPN extension to be able to influence cipher selection, nor is there a requirement for an ALPN to make the cipher that will be selected available to the protocol selection.
Even if ALPN does allow arbitrary selection of cipher/protocol pair, it is impossible for a server to select an acceptable cipher/protocol pair because clients interpretations of 9.2.2 will vary over time and available ciphers. If a server selects a cipher/protocol pair that it believes is h2 acceptable, but the client disagrees, then communication failure results. Thus the moment there are different interpretations of 9.2.2 in the client population it will be impossible for a single h2 server to accept connections from 100% of the population.
The server need only support the minimum requirements in 9.2.2 at the TLS layer, i.e. enable TLSECDHERSAWITHAES128GCM_SHA256 overall and make it a suitably high preference. If the 9.2.2 requirements are increased in the future, then that requires an ALPN bump too and thus it can be deployed without worry.
Note that I think discussion on this topic has moved beyond the specific concerns raised in this issue. This issue should probably be decomposed into: Should we be restricting TLS ciphers within the application protocol draft document The usage of the ALPN handshake is fragile as any differing interpretations of 9.2.2 against future ciphers can result in communication failure. The ALPN RFC does not require that a ALPN implementation provide functionality needed to implement 9.2.2, specifically either to a) use protocol selection to influence the cipher selection; or b) be informed of the cipher selected to influence protocol selection.
Ideally, no, the HTTP/2 spec should not be setting TLS details. HTTP/2 should simply require TLS 1.3, or at least a 1.2.1 with the required improvements done in the relevant spec. This, however, requires a level of coordination between working groups that isn't currently available. This section is just a hack to make a TLS 1.2-h2 variant that's the best that's currently attainable. It's a transitional spec until TLS 1.3 is eventually complete some time in the indeterminate future, just as HTTP/2 is likely to be a transitional spec until HTTP/3 gets written. The cleanest route would be to cut out sections 9.2.1 & 9.2.2 and make a new TLS 1.2.1 spec that satisfies those requirements, then separately publish that and require its usage here. (though, you'd have to come up with some way to handle the minor version number; maybe implement TLS 1.2.1 entirely as an extension) It's probably too late in the HTTP/2 development process to do this, unfortunately, though it would be a cleaner spec with less fiddly bits that can break interoperability.
Discuss on-list, please.
Actually, it's about ethics in game journalism.
Consensus to adopt .

Related discussion:
text: The general TLS usage guidance in TLSBCP SHOULD be followed, with some additional restrictions that are specific to HTTP/2. <del> An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on feature set and cipher suite described in this section.  Due to implementation limitations, it might not be possible to fail TLS negotiation.  An endpoint MUST immediately terminate an HTTP/2 connection that does not meet the TLS requirements described in this section with a ConnectionErrorHandler of type </del> <ins> The TLS implementation MUST support the TLS-EXT extension to TLS. HTTP/2 clients MUST indicate the target domain name when negotiating TLS. </ins> <del> . </del> <ins> The restrictions in this and subsequent sections apply only to deployments of HTTP/2.  Implementations SHOULD provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance. </ins> 9.2.1. <del> The TLS implementation MUST support the TLS-EXT extension to TLS. HTTP/2 clients MUST indicate the target domain name when negotiating TLS. </del> <ins> A deployment of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on feature set described in this section.  Due to deployment limitations, it might not be possible to fail TLS negotiation when these restrictions are not met.  An endpoint SHOULD immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a ConnectionErrorHandler of type </ins> <del> The TLS implementation MUST disable compression.  TLS compression can lead to the exposure of information that would not otherwise be </del> <ins> . A deployment of TLS 1.2 MUST disable compression.  TLS compression can lead to the exposure of information that would not otherwise be </ins> revealed RFC3749.  Generic compression is unnecessary since HTTP/2 provides compression features that are more aware of context and therefore likely to be more appropriate for use for performance, security or other reasons. <del> The TLS implementation MUST disable renegotiation.  An endpoint MUST treat a TLS renegotiation as a ConnectionErrorHandler of type </del> <ins> The TLS 1.2 implementation MUST disable renegotiation.  An endpoint MUST treat a TLS renegotiation as a ConnectionErrorHandler of type </ins> .  Note that disabling renegotiation can result in long-lived connections becoming unusable due to limits on the number of messages