Decoder accepts a Sign bit of 1 when Required Insert Count is 0 (RFC 9204 §4.5.1.2 MUST)

[vcarus]

Decoder accepts a Sign bit of 1 when Required Insert Count is 0 (RFC 9204 §4.5.1.2 MUST)

Version: 2.7.0 (9156770); the relevant code is unchanged back through at least 2.6.x.

Summary

lsqpack_dec_read_header accepts an encoded field section whose prefix has the Delta Base Sign bit set to 1 while the Required Insert Count is 0. RFC 9204 §4.5.1.2 requires:

An endpoint MUST treat a field block with a Sign bit of 1 as invalid if the value of Required Insert Count is less than or equal to the value of Delta Base.

When Required Insert Count is 0, every non-negative Delta Base satisfies RIC <= Delta Base, so a Sign bit of 1 is always invalid. The decoder returns success instead.

Mechanism

In the prefix state machine (lsqpack.c, PREFIX_STATE_READ_DELTA_BASE_IDX), the Sign bit is only consulted when a dynamic-table reference was signalled (HBRC_LARGEST_REF_SET). With Required Insert Count 0 the else branch runs and sets the base unconditionally, discarding DELB.sign:

case PREFIX_STATE_READ_DELTA_BASE_IDX:
    r = lsqpack_dec_int(&buf, end, prefix_bits, &DELB.value, &DELB.dec_int_state);
    if (r == 0)
    {
        if (read_ctx->hbrc_flags & HBRC_LARGEST_REF_SET)
        {
            if (DELB.sign)
                read_ctx->hbrc_base_index =
                    ID_MINUS(read_ctx->hbrc_largest_ref, DELB.value + 1);
            else
                read_ctx->hbrc_base_index =
                        ID_PLUS(read_ctx->hbrc_largest_ref, DELB.value);
        }
        else    /* Sign bit is never checked here */
            read_ctx->hbrc_base_index = 0;
        ...

Reproduction

Each of these field sections is accepted (verified with the decoder returning :scheme: https); RFC 9204 §4.5.1.2 requires each to be rejected. Byte 1 is Required Insert Count = 0; byte 2 has the Sign bit (0x80) set with the low 7 bits carrying Delta Base; the remainder is a well-formed representation (0xd7 = Indexed Field Line, static table entry 23, :scheme: https).

00 80 d7
00 81 d7
00 87 d7
00 fe d7
00 ff 00 d7   (Delta Base spelled with a continuation octet)
00 ff 49 d7

Note

Found by a differential decoding oracle run against a third-party HTTP/3 implementation; every other divergence it surfaced adjudicated in ls-qpack's favor or was a deliberate layering choice on our side. This is the one that came out the other way. Reporting it upstream as a courtesy — we do not depend on ls-qpack directly.

[dtikhonov]

Thanks for the report. The behavior described here is real relative to the published RFC, but it is worth recording how this requirement entered the specification and what its practical effect is.

The requirement that Base MUST NOT be negative, and that a field block with Sign == 1 is invalid when Required Insert Count <= Delta Base, was not in the QPACK Internet-Drafts when this decoder behavior was implemented. I checked the published drafts from draft-02 through the final draft-21. They do not contain this prohibition. Instead, they say:

A field section that was encoded without references to the dynamic table can use any value for the Base; setting Delta Base to zero is one of the most efficient encodings.

The prohibition was also absent from the working group's April 2022 pre-RFC source. It appears to have been added during the final RFC publication process.

The implementation follows the earlier specification deliberately. When the Required Insert Count is zero, there can be no dynamic-table references, so the decoder maps the otherwise irrelevant Base to zero. Consequently, the inputs in this report decode to precisely the same field lines as the corresponding valid encodings with a zero Sign bit. They do not modify the dynamic table, produce a Section Acknowledgment, create a different interpretation of a field line, or expose additional application semantics.

RFC 9204 itself notes that "the protocol might operate correctly with a negative Base using post-Base indexing" before prohibiting negative Base as "unnecessary and inefficient." In the specific case reported here, Base is not used at all, so even that inefficiency does not arise. Internally, ls-qpack represents dynamic-table IDs using modular arithmetic, for which a conceptually negative intermediate Base is not intrinsically problematic.

Thus, I agree that this is a strict conformance difference from the final text of RFC 9204. I do not see a decoding-correctness, interoperability, state synchronization, memory-safety, or security consequence. Rejecting these inputs would serve canonicalization and strict conformance-test compliance; it would not change the set of field sections a peer can express.

[vcarus]

Thanks. The history is the useful part here. So the divergence is from text that postdates the implementation, which is a very different thing from a decoder that drifted.

No change requested on my side. I ran into it because I use ls-qpack as an independent decoder in a differential oracle against my own QPACK implementation, where I keep the literal RFC 9204 reading — so the two disagree on exactly this input class. Knowing it's deliberate is what I needed; I'll record it as a known intentional divergence rather than chase it as a mismatch.

I'll leave it to you whether this is worth keeping open as a canonicalization / strict-mode item, or closing.

[dtikhonov]

I had Codex track down exactly what happened with this requirement. The report is below.

My read here is that, essentially, implementations that represented Base using bounded, non-modular arithmetic found negative Base inconvenient. Rather than correcting those implementations to handle the draft’s index arithmetic, the working group elevated their implementation constraint into a protocol-level MUST during the RFC publication process.

I am sorry I was not there to speak up against this change. Now I have to choose whether to add unnecessary checks or to keep ls-qpack non-compliant.

---

Provenance of RFC 9204's Negative-Base Requirement

Conclusion

The negative-Base requirement was a late working-group change made after the final QPACK Internet-Draft had entered the RFC Editor queue.

• Kazuho Oku originated the proposal. He opened QUIC WG issue #4938, “negative base values”, on September 27, 2021.
• Martin Thomson authored the normative text. He wrote commit 0e22ccf, “Negative base values are invalid” and opened PR #4940.
• The substantive discussion occurred on GitHub. The issue and PR contain the design rationale, implementation claims, review, and selection of MUST rather than MAY.
• Working-group consensus was established on the QUIC mailing list. The chairs ran a two-week consensus call covering this and three other late HTTP/3/QPACK issues. There was support and no recorded opposition.
• Mike Bishop merged the change on April 26, 2022, while RFC 9204 was in AUTH48. The published RFC contains the new paragraph.

This was therefore not a requirement inherited from the QPACK drafts on which ls-qpack was originally based, nor does it appear to have been independently invented by the RFC Editor. It was a post-I-D working-group clarification proposed and approved while the document was in the RFC publication process.

Origin and authorship

The final draft-21 did not prohibit negative Base values. It retained this language:

A field section that was encoded without references to the dynamic table can use any value for the Base; setting Delta Base to zero is one of the most efficient encodings.

The prohibition was also absent from the working group's April 4, 2022 pre-RFC source.

Kazuho Oku opened issue #4938 after noticing that the Base formula could produce a negative result but the specification did not forbid it. He asked whether there was consensus that encoders were prohibited from producing such a prefix, while acknowledging that it might be late to change the draft.

The initial GitHub responses were:

• Martin Thomson said his implementation rejected underflow as invalid and that he saw no other way to handle it.
• Mike Bishop called it a possible “reasonable clarification,” said QPACK integers were intended to be positive, and asked for the editor and chairs to weigh in.
• Bence Béky said Google's decoder had rejected negative Base since December 2018 and supported adding the clarification.

Lucas Pardue requested a concrete proposal. Martin Thomson then authored PR #4940, which added:

The value of Base MUST NOT be negative. Though the protocol might operate correctly with a negative base using post-base indexing, it is unnecessary and inefficient. An endpoint MUST treat a field block with an S bit of 1 as invalid if the value of Required Insert Count is less than or equal to the value of Delta Base.

Martin's PR description explicitly acknowledged that signed arithmetic was valid, but argued that allowing it introduced problems and was less efficient. He also said he was willing to use MAY instead of MUST.

Review and choice of normative strength

The PR records three approvals:

• Mike Bishop was ambivalent between MUST and MAY, but favored MUST under the principle that easily detected errors should be mandatory.
• Alan Frindell, the document editor, said he liked MUST. He raised but declined to pursue the analogous positive-overflow case.
• Kazuho Oku approved and confirmed that the PR addressed his issue.

Thus, Kazuho supplied the issue and desired rule; Martin wrote the paragraph; Mike and Alan explicitly supported its normative strength.

Mailing-list consensus

On November 3, 2021, QUIC WG chair Lucas Pardue opened a two-week mailing-list consensus call. The message said that several issues had appeared while the documents were in the RFC Editor queue and that the responsible Area Director had asked the chairs to confirm working-group consensus before incorporating the changes during AUTH48. For “negative base values #4938,” the proposed resolution was PR #4940.

The recorded responses were:

• Martin Thomson agreed with all proposed resolutions and said the changes would otherwise become errata.
• David Schinazi agreed with Martin.
• Mirja Kühlewind said the proposals looked good, while noting that she was not the expert.

On November 22, Lucas Pardue closed the call:

Hearing no pushback, we'll incorporate these changes as described in the initial call.

That same day he applied the GitHub has-consensus label to issue #4938. The repository defines that label as: “An issue that the Chairs have determined has consensus, by canvassing the mailing list.”

Publication timeline

The Datatracker history and GitHub timelines establish the sequence:

Date	Event
February 3, 2021	QPACK draft-21, the final Internet-Draft, was published without the requirement.
February 18, 2021	The IESG moved the document to the RFC Editor queue.
September 13, 2021	The RFC Editor moved the document into EDIT.
September 27, 2021	Kazuho opened issue #4938.
October 4–5, 2021	Martin authored the change and opened PR #4940.
November 3–17, 2021	The QUIC WG mailing-list consensus call ran.
November 22, 2021	The chairs recorded no pushback and marked the issue has-consensus.
February 3, 2022	RFC 9204 entered AUTH48.
April 26, 2022	Mike Bishop merged PR #4940 into the AUTH48 source.
May 27, 2022	AUTH48 completed.
June 2022	RFC 9204 was published with the requirement.

[dtikhonov]

I'd be curious to take a peek at your QPACK implementation, @vcarus!

[vcarus]

Happy to — https://github.com/vcarus/volto (MIT). QPACK is one file, src/h3/qpack.rs, about 800 lines.

It is a much smaller target than ls-qpack, though: the server advertises QPACK_MAX_TABLE_CAPACITY = 0, so there is no dynamic table and no instruction streams — static table and literals only. That is also why rejecting this case was cheap for me: I never use Base at all.

The oracle is tests/interop/difforacle/ — generated and mutated field sections through both decoders (yours via pylsqpack), disagreements grouped by signature. Five stable divergences, each pinned in tests/it_diff_oracle.rs with the bytes and the RFC sentence that settles it:

Input	volto	ls-qpack
Empty field section	accepts	refuses
Zero-length field name	accepts (refused one layer up)	refuses
Integer with continuation octets that add nothing	accepts	refuses
Sign bit 1 with Required Insert Count 0	refuses	accepts
Huffman padding longer than seven bits	refuses	accepts, for some inputs

The first three are ls-qpack being stricter than the text; I read those as deliberate. The last is the only other MUST (RFC 7541 §5.2) I saw ls-qpack not enforce, and unlike this one it is not systematic — appending a single 0xff to four thousand random literals, it refused all but two. I have no theory about what distinguishes those two.