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 TLS_ECDHE_RSA_WITH_AES_128_GCM_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:

1. Should we be restricting TLS ciphers within the application protocol draft document
2. The usage of the ALPN handshake is fragile as any differing interpretations of 9.2.2 against future ciphers can result in communication failure.
3. 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 #644.