Document: draft-ietf-ohai-chunked-ohttp-07
Title: Chunked Oblivious HTTP Messages
Reviewer: Derrell Piper
Review result: Ready with Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is my telechat review of -07.  I previously reviewed -06 during
Last Call [1].

Summary: Ready with Issues

The authors addressed several issues from my Last Call review,
and I appreciate both the changes and the acknowledgment.  The
document is in much better shape.  Three issues remain.

RESOLVED FROM LAST CALL REVIEW

1. Nonce Counter Wraparound (Section 6.2)

Resolved.  Section 6.2 now contains explicit normative text:
"the response MUST NOT use 256^Nn or more chunks."  This directly
addresses my concern about counter wraparound.

2. Message Size Limits (Section 7.3)

Resolved.  Section 7.3 now correctly references Section 6 of
[AEAD-LIMITS] (was Section 7), includes the hard limit on chunk
count (256^Nn), references C_MAX for per-chunk size via [AEAD],
and states these limits apply to both request and response.

3. HPKE Sequence Limit (Section 6.1)

Resolved.  Subsumed by the 256^Nn text in Section 6.2 and the
new Section 7.3 language.

4. "final" AAD Encoding (Section 6.1)

Resolved.  The AAD is now explicitly defined as ASCII "final"
with hex encoding (0x66696e616c).

5. Zero-Length Chunk Prohibition (Section 6, new in -07)

Good addition.  "A non-final chunk MUST NOT contain a zero-length
plaintext" prevents empty chunks from advancing the sequence
counter without carrying data.

REMAINING ISSUES

1. Interactivity and Privacy (Section 7.2) - SHOULD FIX

Section 7.2 is improved.  It now states that the gateway can
observe round-trip time to the client, and that a network
adversary (including the relay) can measure round-trip delay.
However, it lacks normative guidance.

The text says clients "need to be aware of the possibility" of
RTT leakage, but never states what they should do about it.
Specific attacks enabled by this leakage include: fingerprinting
clients across requests by correlating RTT patterns, geographic
inference when the relay location is known, and partitioning
anonymity sets by timing buckets.

I'd suggest adding a normative statement along these lines:

   "Clients that depend on unlinkability SHOULD avoid interactive
   exchanges.  Applications that require interactivity SHOULD
   document the reduced privacy properties compared to base OHTTP
   or non-interactive chunked OHTTP."

Without this, the section reads as an informational observation
rather than actionable security guidance.

2. Message Size Calculation (Section 7.3) - SHOULD CLARIFY

The -06 text said the per-key byte limit was 2^30 (assuming 2^20
concurrent keys).  The -07 text now says 2^40, stating: "the total
number of bytes protected by a key can be kept below 2^80, divided
by the total number of bytes protected by any key."

The conclusion "no message can exceed 2^40 bytes" implies a
symmetric assumption where the total bytes protected by any single
key equals 2^40.  In a real OHTTP deployment, the gateway handles
many concurrent sessions with different keys.  The original -06
calculation with 2^20 keys yielding 2^30 bytes per key was
arguably more conservative and more realistic for a production
gateway.  I'd ask the authors to either clarify the assumption
behind the 2^40 figure or provide a worked example showing how
deployers should calculate their own limits based on expected
concurrent session counts.

3. Replay and Truncation (Section 7.1) - NIT

Section 7.1 correctly identifies the truncation risk but could
benefit from an explicit statement that chunking does not introduce
new full-request replay vulnerabilities beyond those already
present in base OHTTP (Section 6.5 of [OHTTP]).  This would help
readers understand that the novel risk from chunking is truncation,
not replay, and that the HPKE context binding prevents cross-session
chunk mixing.

EDITORIAL

Section 7.3: "These hard Limits on chunk size" should be "These
hard limits on chunk size" (lowercase 'l').

OVERALL

The document is close to ready.  The core cryptographic mechanism
is sound, and the -07 revisions addressed the most critical issues
from my Last Call review.  The remaining gap is normative privacy
guidance in Section 7.2 for interactive use cases.

Derrell

[1] https://datatracker.ietf.org/doc/review-ietf-ohai-chunked-ohttp-06-secdir-lc-piper-2025-10-09/