]> Individual Contributor

Moscow RU egor@egl.sh

ART HTTPBIS Working Group HTTP/2 ALPN TLS 1.2 cipher suite protocol negotiation Section 9.2.2 of RFC 9113 identifies, but does not normatively resolve, a failure mode in which the application protocol and the cipher suite are selected independently, resulting in a successfully completed TLS handshake whose negotiated parameters may be rejected at the HTTP/2 layer with an INADEQUATE_SECURITY connection error. This document addresses that gap by adding a SHOULD-level procedure that coordinates cipher suite selection with ALPN negotiation, and updates RFC9113.

Introduction An interoperability hazard between TLS cipher suite selection and Application-Layer Protocol Negotiation (ALPN) for HTTP/2 over TLS 1.2 was raised in during the drafting of , the predecessor of . The HTTP Working Group's resolution, merged via , introduced the list of prohibited cipher suites now codified in Appendix A of , together with the mandatory cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as a guaranteed-available alternative. This resolution ensures a guaranteed-available h2-compatible cipher suite, but leaves server behavior unspecified when both prohibited and h2-compatible cipher suites are available for negotiation. Section 9.2.2 of notes the resulting failure mode:

• Note that clients might advertise support of cipher suites that are prohibited in order to allow for connection to servers that do not support HTTP/2. This allows servers to select HTTP/1.1 with a cipher suite that is prohibited in HTTP/2. However, this can result in HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected.

When a client chooses to enforce the cipher suite requirements of Section 9.2.2 of , it may signal this by tearing down the HTTP/2 connection via GOAWAY with error code INADEQUATE_SECURITY (Section 7 of ). However, Section 9.2.2 of only acknowledges this failure without prescribing a solution, leaving a preventable failure mode unaddressed. TLS 1.2 remains widely deployed, and this failure mode affects any TLS 1.2 server where prohibited cipher suites are available alongside h2-compatible cipher suites. This document adds a SHOULD-level procedure for coordinating cipher suite selection with ALPN negotiation. It does not modify the prohibited cipher suite list in Appendix A of or the mandatory cipher suite requirement of Section 9.2.2 of . Instead, it closes the normative gap left open by Section 9.2.2 of , which identifies independent selection as a failure mode but does not prescribe how to prevent it when prevention is possible.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The term "ClientHello" is used as defined in Section 7.4.1.2 of . The term "h2-compatible cipher suite" refers to any TLS 1.2 cipher suite that is not listed in Appendix A of .

Applicability This document applies to TLS 1.2 servers that negotiate ALPN and support HTTP/2 . This document does not apply to TLS 1.3 . HTTP/2 over TLS 1.3 is addressed by Section 9.2.3 of . The procedure specified in is most directly relevant to deployments where prohibited cipher suites are present in the negotiation alongside h2-compatible cipher suites.

Cipher Suite Selection Procedure When a TLS 1.2 server receives a ClientHello that includes "h2" in the ALPN extension , and the intersection of cipher suites offered in the ClientHello and supported by the server includes at least one h2-compatible cipher suite, the server SHOULD select an h2-compatible cipher suite.

Security Considerations This document does not modify the cipher suite requirements of Section 9.2.2 of or the list of prohibited cipher suites in Appendix A of . The TLS threat model is unchanged. This procedure addresses an availability concern: it prevents connection failures that occur when a prohibited cipher suite is selected despite an h2-compatible one being available for negotiation.

IANA Considerations This document has no IANA actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. HTTP Working Group HTTP Working Group

Acknowledgments This document was informed by the discussion in and of the httpwg/http2-spec repository, in particular the observation by Sam Hartman at IETF 91 that led to the cipher block list now codified in Appendix A of .