Hacker News Reader

Bit of a leading question since you assuming that this is "complexity bloat" and not just "a feature that people use", but yes, HTTP/3 has streams and so it should be vulnerable.

View on HN

HTTP/3 is not vulnerable to this specific attack (Rapid Reset), because there it has an extra confirmation step before the sender can create a new stream.

HTTP/2 and HTTP/3 both have a limit on the number of simultaneous streams (requests) the sender may create. In HTTP/2, the sender may create a new stream immediately after sending a reset for an existing one. In HTTP/3, the receiver is responsible for extending the stream limit after a stream closes, so there is backpressure limiting how quickly the sender may create streams.

Thanks. I'm curious to see how the backpressure ends up playing out in terms of "do you need 10k boxes to DoS vs 100k vs not feasible".

> assuming that this is "complexity bloat" and not just "a feature that people use"

¿Por qué no los dos?

:)

Bloat implies that it isn't useful - that it's just dead weight.

If a lot of people use the thing, it must provide some value to them.

Well, to me "bloat" and "useful + used" are incompatible. The feature only made it into HTTP/2 because it saw validation from gRPC, I believe.

Reply on news.ycombinator.com