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

[Martin Thomson <[e-mail]>]

This isn't needed.  Reasons:

1. Every HTTP/2 implementation has solved this problem already.

2. The cipher suites that are forbidden in RFC 9113 are very dead.  Any server stack that might support those ciphers will definitely not prefer them over cipher suites that are acceptable to HTTP/2.

3. This isn't a SHOULD.  It's an implicit MUST in RFC 9113 already.  Using SHOULD here is weaker than what RFC 9113 already says.  After all, if you have a SHOULD, you are obligated to provide some guidance for the circumstances under which someone might choose not to follow the recommendation.  https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

On Sat, May 23, 2026, at 23:32, Egor Gudzenko wrote:
> Hi,
>
> I've submitted an individual draft addressing the failure mode noted in 
> Section 9.2.2 of RFC 9113, where HTTP/2 may be negotiated with a 
> prohibited cipher suite.
>
> https://datatracker.ietf.org/doc/draft-gudzenko-httpbis-h2-cipher-selection/
>
> The draft adds a single SHOULD-level procedure: when an h2-compatible 
> cipher suite is available in the negotiation, the server should prefer 
> it. It doesn't change anything normative, and the only subject of this 
> draft is to fill a normative gap that are identified in Section 9.2.2 
> but not described how the server should behave in an ideal world.
>
> I filed it as Standards Track with updates: 9113, since the gap it 
> closes is in normative text and a SHOULD-level addition doesn't fit BCP 
> or Informational cleanly. That said, I'm genuinely uncertain whether 
> this warrants a standalone update to 9113 or whether WG sees a better 
> path.
>
> Any feedback welcome.
>
> With regards,
> Egor Gudzenko
> Attachments:
> * publickey - [e-mail] - 0xAE5C7632.asc
> * signature.asc