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

Hi Lucas,

Thanks for the detailed feedback, and for taking the time to look at the specific examples. The point about ssl_prefer_server_ciphers and the nginx HTTP/2 documentation is well taken, and I agree that the Node.js ordering argument weakens the case.

Your suggestion to open issues against specific implementations that ship poor defaults for HTTP/2 is probably the right approach here.

Cheers,
Egor

On Monday, June 8th, 2026 at 13:40, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:

> 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 version 1.0.2.
> 

> > Also note that if the ssl_prefer_server_ciphers directive is set to the value “`on`”, the ciphers should be configured to comply with RFC 9113, 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
> 

>