Consider restriction to only allow response after complete request

[tfpauly]

In order to simplify analysis and deviate less from the original design of OHTTP, consider adding a restriction to only allow response after complete request.

[tfpauly]

One risk here is that having multiple back-and-forth interactions reveals can reveal timing information to the gateway.

One case where this may still be allowed is Expect 100-continue.

[martinthomson]

I'm not sure that this is necessary. I would instead signpost the risks involved very clearly.

Fundamentally, the goal of OHTTP is to enable the creation of an isolated context. What happens within that context could be arbitrarily complex, provided that the actions taken do not draw on information outside of that context. So you can even string together multiple OHTTP requests, if you are prepared to accept some of the limitations of that. This 100-continue thing leaks too, but maybe that leakage is acceptable.

[martinthomson]

I should mention that any interactive use of OHTTP (the date correction stuff, 100-continue) reveals RTT to the client, which is a privacy leak. That's worth mentioning as an additional concern even if you successfully isolate the interaction in all other ways.

[chris-wood]

On balance, having a mechanism to prevent premature use of chunks (i.e., using chunks before the whole object has been authenticated) feels like the right outcome here. I don't know if signposts would be enough.

[martinthomson]

Isn't that mechanism just "don't use this chunking stuff"?

[chris-wood]

No, I don't think so. I can certainly imagine applications misusing this for performance reasons. It's like the equivalent of using AEAD plaintext before actually checking the tag for integrity.