Lacking commentary on denial of service

[LPardue]

At the May interim I mentioned something about how many implementations or deployments optimise of lowest energy state, picking the more-straightforward way to do things such as ordering in a natural sequence rather than an unpredictable one.

Extensibility, greasing and variability are also vectors for abuse and there are serious DoS considerations that we don't really cover. For example, HTTP/3 Section 10.5 includes this text

The ability to send undefined protocol elements that the peer is required to ignore can be abused to cause a peer to expend additional processing time. This might be done by setting multiple undefined SETTINGS parameters, unknown frame types, or unknown stream types. Note, however, that some uses are entirely legitimate, such as optional-to-understand extensions and padding to increase resistance to traffic analysis.

snip

All these features -- i.e., server push, unknown protocol elements, field compression -- have legitimate uses.
These features become a burden only when they are used unnecessarily or to excess.
An endpoint that does not monitor such behavior exposes itself to a risk of denial-of-service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error of type H3_EXCESSIVE_LOAD, but false positives will result in disrupting valid connections and requests.

Since these recommendations are loose, there is a potential risk that "too much" greasing or variability can trigger issues that are not otherwise seen but the definition of "too much" is opaque and very specific to each implementation or deployment.