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

FTR, I don't see any need to change the protocol; just change the implementations that are vulnerable because their expectations are wrong about clients on the open Internet. That's why many HTTP/2 implementations were already prepared for this attack.

Speaking of which, that CVE is completely irresponsible. A CVE is supposed to list known vulnerabilities in released software, not potential vulnerabilities in all implementations of a single protocol. Now we have security poodles from all over the world asking each and every HTTP project whether they have a fix for a vulnerability that they never had in the first place, all because the CVE authors prefer to blame the protocol instead of their own internet-facing implementations. Don't do that, especially not for a low severity DDoS load-based attack. It has created a DDoS of its own, killing time we have for all of our open source projects, and we don't scale like a server.

The RFC cannot guess what is the appropriate number of max concurrent streams for a given interface because h2 might be used in both trusted and untrusted environments, with both custom and generic clients, and with a great deal of variance in server capabilities (memory and CPU). It is fair to say that any server should be capable of receiving 100 concurrent stream openings. That does not mean the server has to provide an equal service to those 100 open streams, nor does it say that a server has to ignore the reset streams count just because the client said so. The server is in control of the interface and is fully capable of adjusting its services regardless of the RFC. The server can make the choice of availability versus interoperability far better than we can.

The working group should prepare a detailed explanation for a Security Considerations section that describes how such attacks work and how they can be mitigated by reducing service allocations to misbehaving clients. There is no need to change the protocol itself, other than to acknowledge (once again) that anything specified by the protocol is subject to change by the server if it perceives the client to be an attack rather than an interoperable client.

Cheers,

.....Roy

Received on Saturday, 14 October 2023 18:21:20 UTC