Code change:
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

Related discussion:
text: 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 .