RE: Prague side meeting: HTTP/2 concurrency and request cancellation (CVE-2023-44487)

[Mike Bishop <[e-mail]>]

That might be exactly what we need. This has been a problem for many of us for a while, despite it being publicly discussed only recently. While your draft is a fine patch for well-behaved clients, the reality is that attackers will simply play dumb and pretend to be unextended HTTP/2 clients. Other mitigations will still be needed as long as that connection pattern is allowed.  (And reducing the default or recommended value does nothing to mitigate this particular attack, so I'm not particularly concerned about it.  Servers will enforce their actual value from the start of the connection and RESET and excess streams anyway.)

What servers would need is the ability to deny the use of HTTP/2 unless this mechanism is supported.  That implies an ability to consider the presence of this extension when the server is deciding which of the client's ALPNs to select.

ALPS might be a solution, but the interplay between ALPS and ALPN would be unpleasant, even if it were already present and usable in most stacks. Something like that feels like a better answer to things which will influence the first flight, but not influence the protocol selection.

When we designed the HTTP/2 extension mechanism, we took a hard stance against embedding extension IDs in the ALPN, because of the potential explosion of IDs as multiple extensions were supported.  But for a case where we might change support of a protocol based on the absence of certain extensions, an ALPN token could be warranted.

How's "h2.1"?

-----Original Message-----
From: Martin Thomson <[e-mail]> 
Sent: Thursday, October 12, 2023 12:42 AM
To: Glenn Strauss <[e-mail]>
Cc: Willy Tarreau <[e-mail]>; Mark Nottingham <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: Prague side meeting: HTTP/2 concurrency and request cancellation (CVE-2023-44487)

On Thu, Oct 12, 2023, at 15:38, Glenn Strauss wrote:
> Related, I support a future RFC changing the initial setting for 
> HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS to something much more limited, 
> such as 10.  (FYI: lighttpd sends SETTINGS_MAX_CONCURRENT_STREAMS 8.)

Unfortunately, in order to do that, we would need to define a completely new protocol that is identified by a different ALPN token, like "h2-but-not-as-vulnerable-to-DoS".

I agree that the initial value is bad (a limit of 2^30 is just absurd), but I'm not sure that the cost of fixing this is justified.

Teaching clients cope better with lower concurrency limits (like 8) is probably our best course of action here.