Re: Draft: Cipher Suite Selection for HTTP/2 Negotiation over TLS 1.2

Hi ,

Lets pick at your nginx example since I'm most familiar that implementation.


On Mon, 8 Jun 2026, 00:13 Egor Gudzenko, <egor@egl.sh> wrote:

>
>
> **General-purpose web servers.** nginx's documented default is ssl_ciphers
> HIGH:!aNULL:!MD5. [5]
>
>
> [5] Configuring HTTPS servers. nginx documentation.
>     https://nginx.org/en/docs/http/configuring_https_servers.html


This is using the wrong documentation to support the point. Nginx's docs
for HTTP/2 provide an example config [1] with the following supporting text

>  Note that accepting HTTP/2 connections over TLS requires the
“Application-Layer Protocol Negotiation” (ALPN) TLS extension support,
which is available since OpenSSL <http://www.openssl.org> version 1.0.2.

> Also note that if the ssl_prefer_server_ciphers
<https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_ciphers>
directive is set to the value “on”, the ciphers
<https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers>
should be configured to comply with RFC 9113, Appendix A
<https://datatracker.ietf.org/doc/html/rfc9113#appendix-A> black list and
supported by clients.

Switching to node.js, the wall of text claims CBC ciphers are explicitly
included in the documentation, which does appear to actually be the case
[2]:


node -p crypto.constants.defaultCoreCipherList | tr ':' '\n'

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

ECDHE-RSA-AES128-GCM-SHA256

ECDHE-ECDSA-AES128-GCM-SHA256

ECDHE-RSA-AES256-GCM-SHA384

ECDHE-ECDSA-AES256-GCM-SHA384

DHE-RSA-AES128-GCM-SHA256

ECDHE-RSA-AES128-SHA256

DHE-RSA-AES128-SHA256

ECDHE-RSA-AES256-SHA384

DHE-RSA-AES256-SHA384

ECDHE-RSA-AES256-SHA256

DHE-RSA-AES256-SHA256

HIGH

!aNULL

!eNULL

!EXPORT

!DES

!RC4

!MD5

!PSK

!SRP

!CAMELLIA
While "HIGH" implicitly includes CBC, the ciphersuite ordering there
prefers other RFC 9113 compatible ciphers.

Based on these two examples I don't think there's value in another IETF
document that tries to do anything in this space. Configuring cipher
preferences is already an annoying aspect of software deployment, I can't
see there being much interest in trying to make the cipher list
configuration grammar more complex to factor in ALPN. Nor can I see crypto
libs being much interested in changes in this space.

At the end of the day, if there are implementations that ship default
support for HTTP/2, with poor defaults for HTTP/2, then the best course of
action is likely to be to open an issue against them.

Cheers
Lucas

[1] https://nginx.org/en/docs/http/ngx_http_v2_module.html#example
[2] https://nodejs.org/api/tls.html#modifying-the-default-tls-cipher-suite