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

On Thu, Oct 12, 2023 at 03:42:11PM +1100, Martin Thomson wrote:
> 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.

RFC 9113:
"It is recommended that this value be no smaller than 100, so as to not
unnecessarily limit parallelism."

How might I convince you to change the guidance, which is "recommended"
and not "MUST"? :)

If that were to be updated to "recommend" 8 or 10, until the server has
had a chance to send SETTINGS_MAX_CONCURRENT_STREAMS immediately
following the HTTP/2 server preface, then I could petition the most
popular clients to *start* with the smaller assumption before receiving
the server SETTINGS frame.

Intent: I posted with the hope that along with the potentially new
MAX_STREAMS, that the guidance for SETTINGS_MAX_CONCURRENT_STREAMS
can also be updated.

Cheers, Glenn

Aside: due to request flood attacks, I do think it a valid argument to
consider changing initial setting of SETTINGS_MAX_CONCURRENT_STREAMS
from unlimited to something limited, and to add guidance for
implementers that they might wish to support 100 *initial* requests or
until receiving SETTINGS acknowledgement, whichever comes first, as long
as the server sends SETTINGS_MAX_CONCURRENT_STREAMS with its SETTINGS
frame.

Received on Thursday, 12 October 2023 05:23:24 UTC