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

On Thu, Oct 12, 2023 at 04:35:57PM +1100, Martin Thomson wrote:
> But in justifying that change, you aren't just arguing that a 100 should be a
> 10 (or whatever), you are also arguing that we need to go through the entire
> process of updating an RFC.  That means not just agreeing that 10 is better
> than 100, but also agreeing that all the work necessary to draft and publish
> a revised RFC is also worth it because that 10 is that much better than the
> 100.

The process which can speed such things up is the errata but there's no
error here, the intent is clearly stated even if it's absurd. At best it
could be stated that clients are encouraged to stick to lower values when
no limit is presented to them, but that could have the inverse effect as
desired, by showing server implementers that the defaults have become safe
over time.

Regardless, there's no point in trying to change the default value anymore
since due to this issue, very likely that the rare servers that would
previously not emit such a limit will now start to emit one anyway. Also,
as Kazuho said, even low values are not a protection.

If an update was deserved, it would definitely be to change the algorithm
itself and adopt something like your proposal which transfers the control
of stream creation acceptance to the server while remaining backward
compatible. That's clearly something I intend to implement to get rid of
this old annoyance, as it will also finally help us implement cleaner
graceful connection closures by refusing to offer new streams to the
client without having to send early GOAWAY frames.

Willy

Received on Thursday, 12 October 2023 06:15:19 UTC