Open egorbaty opened 1 month ago
CONTINUATION was just pwned in the wild. If we are adding a similar design, we'll want to hash out all the security considerations up front
https://nowotarski.info/http2-continuation-flood-technical-details/
Would the producer of the EA know the size upfront? If so I'd prefer a design where the sender declares the total size of thing, rather than as a set of chunks.
Furthermore, perhaps consider a setting that declares the maximum size of EA that would be accepted by the recipient.
Would the producer of the EA know the size upfront? If so I'd prefer a design where the sender declares the total size of thing, rather than as a set of chunks.
Furthermore, perhaps consider a setting that declares the maximum size of EA that would be accepted by the recipient.
I'm not entirely understanding how this differs from the current proposed design. Would we essentially be saying that CERTIFICATE frames would be allowed to have an infinite size and block the control stream?
Part of the story with CONTINUATION is that endpoints tend to have limits on the size of header field sections that they allow. But CONTINUATION was able to defeat that in some cases, because its just an unbounded series of frames with no declaration of the total length upfront. Vulnerable implementations were exploited in a number of ways when processing each frames content. Lots of implementations already mitigated it no problem due to said extant limits.
If I'm understanding correctly, we are considering adding a similar model, so we need to think about limits.
Post IETF-120 update:
A number of different solutions have been proposed here:
TO_BE_CONTINUED
without any other information. Problematic in similar ways as CONTINUATION
is. CONTINUATION
frames to the control stream for use with CERTIFICATE
frames. Does not address issues with CONTINUATION
CERTIFICATE
frames. Suffers head-of-line blocking over TCP but is very simple to implement and doesn't open up CONTINUATION
flood style problems.CERTIFICATE
frames and define separate rules. Adds a lot of extra complexity to get around HTTP/2 limitations.Waiving the maximum frame size is by far the easiest solution. We might want to determine whether this actually causes any suffering or not (since most EAs today should not be much larger than a single frame anyway)
To clarify, does waiving mean ignoring the value of SETTINGS_MAX_FRAME_SIZE when sending or receiving this frame? Such that the maximum length becomes 2^24-1?
If so, maybe it would be good to state that HTTP/3 must also apply this limit to just his frame, to make it easier to pass between proxies that convert between versions.
To clarify, does waiving mean ignoring the value of SETTINGS_MAX_FRAME_SIZE when sending or receiving this frame? Such that the maximum length becomes 2^24-1?
If so, maybe it would be good to state that HTTP/3 must also apply this limit to just his frame, to make it easier to pass between proxies that convert between versions.
Yup.
And yeah, to the point about applying the limit to H3 as well: Presumably this limit should be plenty so even though the limitation doesn't technically have to exist; imposing it universally could simplify implementations.
I can check on the mailing list but maybe this is the direction we head in for now.
That seems reasonable. It also has the side benefit that the length is indeed stated at the front. The trouble with CONTINUATION is that you have to process the chunks, but all each chunk declares is whether it's the end yet. (Because header compression may be streaming.) In this case, I don't see a scenario where the server would stream these -- it will possess the entire EA in a buffer whose length can be known before beginning to write the frame.
The size of exported authenticators (especially with post quantum certificates) could be large enough that they might not fit in the maximum frame size for HTTP/2, so we'd probably want the ability to send them in multiple frames, similar to
CONTINUATION
frames.We cannot actually use
CONTINUATION
frames per HTTP/2 6.10:One possible solution here that minimizes complexity is to just add a
TO_BE_CONTINUED
flag for theCERTIFICATE
frame type, and make it such that the client must assumeCERTIFICATE
frames following a receivedCERTIFICATE
frame are continuations of the previously received authenticator fragment. The authenticator would be complete upon receipt of a frame that does not have the flag set.If that is the form the solution takes, we also might want text that suggests for clients to limit the total size of an authenticator that they would receive to prevent abuse.