HTTP/2 AES-256
Internet-Draft draft-http2-aes256-00
Jason Freedman, Ed.
CYMERTEK
Larry Stark, Ed.
CYMERTEK
Justin Oliver, Ed.
CYMERTEK
2024-05
Applications and Real-Time
HTTPbis
HTTP
SPDY
Web
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to http/2.
Introduction
The optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP)[RFC9113], referred to as HTTP version 2 (HTTP/2)[RFC9113] specifies a requirement of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 which does not meet the needs of a post-quantum cryptography world. In order to allow for stronger cryptography to be enforced, this document specifies an amendement to the original specification.
Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Cipher Requirements
In the HTTP/2 specification [RFC9113], section 9.2.2, paragraph 4, it is explicitly stated that any deployment of HTTP/2 using TLS 1.2 [RFC9113] must adhere to certain cipher suite requirement. In order to contend with post-quantum cryptographic abilities, this document specifies alternate cipher requirements.
With this document, as like the original, the need to mitigate the risk of non-intersecting sets of permitted cipher suites causing TLS handshake failures continues to be a real problem. To avoid this problem, HTTP/2 deployments using TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 [TLS-ECDHE], both with the P-256 elliptic curve [RFC8422].
Additionally, server implementations of HTTP/2 MUST also include an end-user system administrator configurable option to deactivate the lower cipher option, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, in favor of the higher one, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. The default should always be to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which maintains backward compatibility for devices with lower encryption requirements. This end-user disabling switch is essential for those specific instances where the target application necessitates a higher level of cipher strength.
IANA Considerations
This addendum includes no additional request to IANA than what has been requested in HTTP/2[RFC9113].
Security Considerations
This addendum the same ciphers as defined in HTTP/2[RFC9113] and adds an additional required stronger cipher for post-quantum security.
References
Normative References
[RFC9110]

HTTP Semantics
Roy Fielding, Ed.
Mark Nottingham, Ed.
Julian Reschke, Ed.
June 2022
STD 97
RFC 9110
DOI 10.17487/RFC9110
[RFC9113]

HTTP/2
Martin Thomson, Ed.
Cory Benfield, Ed.
June 2022
RFC 9113
DOI 10.17487/RFC9113
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8422]

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
Y. Nir
S. Josefsson
M. Pegourie-Gonnard
August 2018
RFC 8422
DOI 10.17487/RFC8422
[RFC5289]

TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
E. Rescorla
August 2008
RFC 5289
DOI 10.17487/RFC5289
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.2
T. Dierks
E. Rescorla
August 2008
RFC 8446
DOI 10.17487/RFC8446
Authors' Addresses
Jason Freedman, Ed.
CYMERTEK
jasonfreedman@cymertek.com
Larry Stark, Ed.
CYMERTEK
larrystark@cymertek.com
Justin Oliver, Ed.
CYMERTEK
justinoliver@cymertek.com