Session Date/Time: 18 Mar 2024 07:30

ohai

Summary

This session covered two main topics: a draft for chunked oblivious HTTP messages and a proposed use case for an unreliable OHTTP extension in support of private metrics. The chunked OHTTP draft aims to improve efficiency by allowing for incremental encryption and decryption. The unreliable OHTTP extension explores mechanisms for improving privacy by allowing relays to reshuffle and batch requests.

Key Discussion Points

Chunked OHTTP Negotiation: Discussion centered on how to negotiate the use of chunked OHTTP. Options included out-of-band configuration, client-initiated content encoding support, and "just trying" the chunked variant. Concerns were raised about consistency and potential information leaks if chunking is not used consistently.
Chunked OHTTP Max Chunk Size: Participants discussed the need for a maximum chunk size to prevent excessive memory usage and potential denial-of-service attacks. A recommendation for a default maximum chunk size was favored, without a strict requirement for negotiation.
Unreliable OHTTP Use Case: Lin Mao Song presented a use case for an unreliable OHTTP extension in a distributed aggregation protocol (DAP) setting. This extension would allow relays to reshuffle and batch requests to mitigate potential correlation attacks based on request timing and ordering.
Unreliable OHTTP and HTTP Semantics: Concerns were raised about the potential for the unreliable OHTTP extension to change the fundamental semantics of HTTP, particularly regarding expectations of immediate responses. Existing mechanisms like the 202 Accepted status code were discussed as possible alternatives.

Decisions and Action Items

Chunked OHTTP Negotiation: The group decided not to mandate a specific negotiation mechanism for chunked OHTTP. The draft will describe patterns of use, including out-of-band configuration and "trying" the chunked variant, with guidance on ensuring consistency.
Chunked OHTTP Max Chunk Size: The draft will include a recommendation for a default maximum chunk size for interoperability. The specific value will be determined later.
Chunked OHTTP Further Actions: Add formal analysis and test vectors. Improve privacy and security considerations in the document.
Unreliable OHTTP Next Steps: No clear decision was made on adopting the unreliable OHTTP extension. Proponents are encouraged to further evaluate the need for the extension and explore alternative approaches that minimize changes to HTTP semantics. It was also recommended to have discussion with HTTP working group on possible implications of this work.

Next Steps

Tommy Poly will update the chunked OHTTP draft based on the feedback received, including adding recommendations for max chunk size and clarifying usage patterns.
Lin Mao Song to re-evaluate the proposal for unreliable OHTTP and consider discussion with HTTP working group.