Session Date/Time: 11 Dec 2024 20:00

OHAI

Summary

The OHAI working group held its second virtual interim to discuss the draft-ietf-ohai-chunked-ohttp-messages-03 draft. Key updates include requiring matching chunked media types for requests and responses, defining a minimum maximum plaintext chunk size of 16KB, and clarifying the signaling of the last chunk using a zero-length field. A significant portion of the discussion focused on enhanced security considerations regarding interactivity, particularly how client behavior conditioned on server responses can reveal timing information and introduce replay risks. The group decided not to block the Working Group Last Call (WGLC) for formal analysis or for the dependent incremental header field document, but to proceed with WGLC and a parallel media type review once test vectors are generated and validated.

Key Discussion Points

Chunked Media Type Matching: The draft now mandates that if a request uses a chunked media type, the response must also use the same. This simplifies negotiation and configuration. Clients are advised to consistently use one media type to avoid partitioning risks. The resolution was generally supported as sensible.
Maximum Chunk Size: A minimum maximum plaintext chunk size of 16KB is now required for implementations. This size mirrors TLS record sizes for consistency and refers to the plaintext content before any encapsulation. Implementations are permitted to use larger sizes if supported by peers.
Last Chunk Signaling: The mechanism for identifying the last chunk, which uses a zero-length field, was clarified in the document's text and pseudocode. This update addresses previous confusion, particularly noted by Martin during implementation, and was confirmed to align with existing implementation.
Security Considerations for Interactivity:
- Significant textual changes were made to define and elaborate on interactivity, characterizing it as any case where the client request's content or timing is influenced by the response.
- The document highlights that non-interactive modes (e.g., sending the entire request in a single chunk or all request chunks before any response) inherently do not introduce interactivity-related security concerns.
- It clarifies that the client controls whether interactivity occurs. Opting into interactive modes (e.g., for HTTP 100-Continue) implies accepting the associated risks of timing leakage and potential replay.
- Martin emphasized that interactivity does not provide replay risk reduction in this context due to the lack of perfect forward secrecy.
- The group discussed the complex implications of conditioning client behavior on server responses, noting that this naturally reveals Round Trip Time (RTT) and can engage replay risks in new ways. The general recommendation is to avoid such conditioning unless explicit linking of requests is desired (e.g., for certain large file upload scenarios). This section is anticipated to receive further scrutiny during reviews.
Formal Analysis: An open issue regarding formal analysis of the protocol was discussed. The group indicated that while formal analysis is valuable, it should not act as a blocker for proceeding to Working Group Last Call.
Dependency on Incremental Header Field: The draft-ietf-httpbis-incremental-header document is a normative dependency. The group affirmed the intention to maintain this normative dependency, believing the current "SHOULD" guidance for clients is appropriate and that the HTTP working group will likely stabilize the header's shape within a reasonable timeframe (e.g., 6 months), avoiding indefinite blocking of the OHAI draft.
HTTP-DUR and Media Type Review: The need for the HTTP working group to be aware of the OHAI Working Group Last Call was noted, given community overlap. A formal media type review request will also be necessary.

Decisions and Action Items

Decisions

The working group will proceed with Working Group Last Call (WGLC) for draft-ietf-ohai-chunked-ohttp-messages after test vectors are finalized and validated.
Formal analysis of the protocol will not be a blocker for the WGLC.
The normative dependency on the draft-ietf-httpbis-incremental-header will be maintained.
A formal media type review request will be initiated in parallel with the WGLC.

Action Items

Tommy, Martin, Chris: Generate and validate test vectors for the draft-ietf-ohai-chunked-ohttp-messages draft from existing implementations.
Tommy: Send an email to the working group mailing list summarizing the changes introduced in draft-ietf-ohai-chunked-ohttp-messages-03.
Chairs: Initiate the Working Group Last Call (WGLC) for draft-ietf-ohai-chunked-ohttp-messages once test vectors are generated and validated.
Chairs: Ensure the HTTP working group is made aware of the OHAI WGLC.
Chairs: Initiate the formal media type review in parallel with the WGLC.

Next Steps

Generate and validate test vectors for the draft.
Initiate the Working Group Last Call for the chunked-ohttp-messages draft.
Concurrently request a formal media type review.
Monitor feedback from the WGLC and media type review for any further required revisions.