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: unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSFeatures). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.