[secdir] Re: draft-ietf-ohai-chunked-ohttp-07 telechat Secdir review

[Martin Thomson <[e-mail]>]

Hi Derrell,

Thanks again for spending the time on this:

https://github.com/ietf-wg-ohai/draft-ohai-chunked-ohttp/pull/59 has the changes I noted below (and some besides).  I've added some notes to the pull request in addition to the below.

On Sat, Feb 7, 2026, at 01:29, Derrell Piper via Datatracker wrote:
> 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."

Unlinkability isn't quite the right measure here.  The risk to unlinkability comes from the additional information that the gateway (and others) might gain via interactivity.  That is, an attempt to link requests might be able to isolate based on RTT or other information from interaction patterns.  But there is also the potential to leak something about geographic or network location that is still a privacy risk, even when it does not improve the ability to link requests.

Still, it's good suggestion.  I've made a tweak along the lines you describe, recommending against interactivity and requesting an analysis of the privacy risk if it is needed.  

As a side note, I don't think that interactivity is a great reason to use this format. For interactivity, much of the latency advantage can be obtained by using a proxy, TLS, and 0-RTT.  Incremental processing has always been the key feature for me, personally. So I'm down for stronger language discouraging interactivity.

> The conclusion "no message can exceed 2^40 bytes" ...

https://github.com/ietf-wg-ohai/draft-ohai-chunked-ohttp/pull/48/changes is where the change was made (since then, the other draft has changed and the section reference needs to be updated, which I've done.

The analysis is simple.  Here's the base formula for AEA:

q + v <= min( sqrt(p) * 2^76,  p * 2^126 / (L * B) )

For p = 2^-50, the first term is 2^51, so we ignore that.  So we have:

q + v <= 2^76 / L / B

Now, L and B are in 2^4 byte blocks because we assume the worst case for this and they are the same value then (the number of blocks under a single key and the number of bytes under any key; if you chunk things, you can get larger or more messages, which I've noted).  So you have:

num_of_messages * length_in_bytes^2 <= 2^80

So that is how we got to the 1 million queries (2^20) => length of 2^30.  And you are right to check.  I don't have the working for the original change.  It looks like a straight up error.  (Also, redoing this sort of analysis makes me wonder if either our security targets are too conservative, our ciphers are too weak, or both...)